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Neighbors, please join me in reading this fif- 
teenth release of the International Journal of Proof 
of Concept or Get the Fuck Out, a friendly little 
collection of articles for ladies and gentlemen of dis- 
tinguished ability and taste in the field of reverse 
engineering and the study of weird machines. This 
release is a gift to our fine neighbors in Heidelberg, 
Canberra, and Miami. 

If you are missing the first fourteen issues, we 
suggest asking a neighbor who picked up a copy of 
the first in Vegas, the second in Sao Paulo, the third 
in Hamburg, the fourth in Heidelberg, the fifth in 
Montréal, the sixth in Las Vegas, the seventh from 
his parents’ inkjet printer during the Thanksgiv- 
ing holiday, the eighth in Heidelberg, the ninth in 
Montréal, the tenth in Novi Sad or Stockholm, the 
eleventh in Washington D.C., the twelfth in Heidel- 
berg, the thirteenth in Montréal, or the fourteenth 
release in Sao Paulo, San Diego, or Budapest. 

After our paper release, and only when quality 
control has been passed, we will make an electronic 
release named pocorgtfo14.pdf. It is a valid PDF, 
ZIP, and a cartridge ROM for the Nintendo Enter- 
tainment System (NES). 

On page 5, Vicki Pfau shares with us the story 
of how she reverse engineered the Pokémon Z-Ring, 
an accessory for the Nintendo 3DS whose wireless 
connection uses audio, rather than radio. In true 
PoC||GTFO spirit, she then re-implements this pro- 
tocol for the classic GameBoy. 

Pastor Manul Laphroaig is back with a new 
sermon on page 12 concerning Liet Kynes, water, 
Desert Studies, and the Weirding Way. 














Taylor Hornby on page 14 shares with us some 
handy techniques for communicating between pro- 
cessors by reading shared memory pages, without 
writes. 


Mike Meyers on page 19 shares some tricks for 
breaking Windows user-mode keyloggers through 
the injection of fake events. 


Niek Timmers and Albert Spruyt consider a 
rather specific, but in these days important, ques- 
tion in exploitation: suppose that there is a region 
of memory that is encrypted, but not validated or 
write-protected. You haven’t got the key, so you’re 
able to corrupt it, but only in multiples of the block 
size and only without a clue as to which bits will 
become what. On page 26, they calculate the odds 
of that corrupted code becoming the equivalent of 
a NOP sled in ARM and Thumb, in userland and 
kernel, on bare metal and in emulation. 


In PoC||GTFO 13:4, Micah Elizabeth Scott 
shared with us her epic tale of hacking a Wacom 
tablet. Her firmware dump in that article depended 
upon voltage-glitching a device over USB, which is 
made considerably easier by underclocking both the 
target and the USB bus. That was possible because 
she used the synchronous clock on an SPI bus to 
shuffle USB packets between her underclocked do- 
main and realtime. In her latest article, to be found 
on page 30, she explains how to bridge an under- 
clocked Ethernet network by routing packets over 


GDB, OpenOCD, and a JTAG/SWD bus. 








Geoff Chappel is back again, ready to take you to 
a Windows Wonderland, where you will first achieve 
a Mad Hatter’s enlightenment, then wonder what 
the Caterpillar was smoking. Seven years after the 
Stuxnet hype, you will finally get the straight ex- 
planation of how its Control Panel shortcuts were 
abused. Just as in 2010, when he warned that bugs 
might remain, and in 2015 when Microsoft admitted 
that bugs did in fact remain, Geoff still thinks that 
some funny behaviors are lurking inside of the Con- 
trol Panel and .LNK files. You will find his article 
on page 37, and remember what the dormouse said! 

With the recent publication of a collided SHA1 
PDF by the good neighbors at CWI and Google Re- 
search, folks have asked us to begin publishing SHA1 
hashes instead of the MD5 sums that we tradition- 
ally publish. We might begin that in our next re- 
lease, but for now, we received a flurry of nifty MD5 
collisions. On page 46, Greg Kopf will show you 
how to make a PostScript image that contains its 
own checksum. On page 50, Mako describes a nifty 
trick for doing the same to a PDF, and on page 53 
is Kristoffer Janke’s trick for generating a GIF that 
contains its own MD5 checksum. 

On page 56, the Evans Sultanik and Teran de- 
scribe how they coerced this PDF to be an NES 
ROM that, when run, prints its own MD5 check- 
sum. 
On page 60, the last page, we pass around the 
collection plate. Our church has no interest in cash 
or wooden nickels, but we’d love your donation of a 
nifty reverse engineering story. Please send one our 
way. 
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The Ideal 
High Frequency 
Tuner! 


The *HF" is a single section tun- 
ing capacitor, employing the same 
rotor and stator design found in 
the famous Hammarlund “APC” 
which is still recognized after 20 
years as the standard capacitor of 
its type. Extra long sleeve bearing 
and positive contact nickel-plated 
phosphor bronze wiper make the 
"HF" ideally suited to high fre- 
quency applications. 

Silicone treated steatite insula- 
tion. Single hole or base mounting. 
Special spacing or capacity values, 
fnishes and other modifications 
are available to manufacturers on 
speciai order. 


For your free copy of The 
Hammarlund Capacitor Cat- 
alog, which gives listings 
of the complete line of 
standard capacitors, write 
to The Hammarlund Manu- 
facturing Co., Inc., 460 
West 34th St., New York 1, 
N. Y. Ask for Bulletin C1, 


14:02 Z-Ring Phreaking from a Gameboy 


At the end of last year (following their usual 
three-year cycle), Nintendo released a new gener- 
ation of Pokémon games for their latest portable 
console, the Nintendo 3DS. This time, their new 
entry in the series spectacularly destroyed several 
sales records, becoming the most pre-ordered game 
in Nintendo’s history. And of course, along with a 
new Pokémon title, there are always several things 
that follow suit, such as a new season of the long 
running anime, a flood of cheapo toys, and datamin- 
ing the latest games into oblivion. This article is 
not about the anime or the datamining; rather, it’s 
about one of the cheapo toys. 


The two new games, Pokémon Sun and Pokémon 
Moon, focus on a series of four islands known as 
Alola in the middle of the ocean. Alola is totally 
not Hawaii! The game opens with a cutscene of a 
mysterious girl holding a bag and running away from 
several other mysterious figures. Near the beginning 
of the game, the player character runs into this mys- 
tery girl, known as Lillie, as she runs up to a bridge, 
and a rare Pokémon named Nebby pops out of the 
bag and refuses to go back in. It shudders in fear on 
the bridge as it’s harried by a pack of birds—sorry, 
Flying type—Pokémons. ‘The player character runs 
up to protect the Pokémon, but instead gets pecked 
at mercilessly. 
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lYes it is. 


?Did I mention that we're not in Hawaii? I was lying. 


by Vicki Pfau 


Nebby responds by blowing up the bridge. The 
player and Nebby fall to their certain doom, only 
to be saved by the Guardian Pokémon of the is- 
land, Tapu Koko, who grabs them right before they 
hit the bottom of the ravine. Tapu Koko flies up 
to where Lillie is watching in awe, and delivers the 
pair along with an ugly stone that happens to have 
a well-defined Z shape on it. This sparkling stone 
is crafted by the kahuna of the island? into what is 
known as a Z-Ring. So obviously there's a toy of 
this. 





In the game, the Z-Ring is an ugly, bulky stone 
bracelet given to random 11-year old children. You 
shove sparkling Z-Crystals onto it, and it lets you 
activate special Z-Powers on your Pokémon, unlock- 
ing super-special-ultimate Z-Moves to devastate an 
opponent. In real life, the Z-Ring is an ugly, bulky 
plastic bracelet given to random 11-year old chil- 
dren. You shove plastic Z-Crystals onto it, and it 
plays super-compressed audio as lights flash, and 
the ring vibrates a bit. More importantly, when 
you activate a Z-Power in-game, it somehow signals 
the physical Z-Ring to play the associated sound, re- 
gardless of which cheap plastic polyhedron you have 
inserted into it at the time. How does it communi- 
cate? Some people speculated about whether the in- 
terface was Bluetooth LE or a custom wireless com- 
munication protocol, but I have not seen anyone else 
reverse it. I decided to dig in myself. 





The toy is rather overpriced compared to its 
build quality, but, having seen one at a store re- 
cently, I decided to pick it up and take a look. Af- 
ter all, I'd done only minimal hardware reversing, 
and this seemed to be a good excuse to do more. 
The package included the Z-Ring bracelet, three Z- 
Crystals, and a little Pikachu toy. ‘Trying to unbox 
it, I discovered that the packaging was horrendous. 
It's difficult to remove all of the components with- 
out breaking anything. I feel sorry for all of the kids 
who got this for Christmas and then promptly broke 
off Pikachu's tail as they eagerly tried to remove it 
from the plastic. 





The bracelet itself has slots on the sides to hold 
six Z-Crystals and one on the top that has the signa- 
ture giant Z around it. ‘The slot on the top has three 
pogo pins, which connect to pads on a Z-Crystal. 
The center of these is GND, with one pin being used 
to light the LED through a series resistor (R1, 56 Q) 
and the other pin being used to sense an identity re- 
sistor (R2, 18 kQ for green). 


It also has a tri-state switch on the side. One set- 
ting (Mode I) is for synchronizing to a 3DS, another 
(Mode II) is for role-play and synchronizes with six 
tracks on the Sun/Moon soundtrack, and the final 
(neutral) setting is the closest thing it has to an off 
mode. A button on the side will still light up the 
device in the neutral setting, presumably for store 
demo reasons. 


My first step in trying to reverse engineer the 
device was figuring out how to pair it with my 3DS. 
Having beaten my copy of Pokémon Sun already, I 
presumably had obtained anything needed in-game 
to pair with the device, but there was no explicit 
mention of the toy in-game. Included in the toy's 
packaging were two tiny pamphlets, one of which 
was an instruction manual. However, the instruc- 
tion manual was extremely minimal and mostly just 
described how to use the toy on its own. The only 
thing I could find about the 3D5 interface was an 
instruction to turn up the 3DS volume and set the 
audio to stereo. There was also a little icon of head- 
phones with a line through them. I realized that 
it didn't pair with the 3DS at all. It was sound- 
triggered! 

I pulled out my 3D$, loaded up the game, and 
tried using a Z-Power in-game with the associated Z- 
Crystal inserted into the top of the toy. Sure enough, 
with the sound all the way up, the Z-Ring activated 
and synchronized with what the game was doing. 

Now that I knew I'd need to record audio from 
the game, I pulled up Audacity on my laptop and 
started recording game audio from the speakers. Ex- 


pecting the audio to be in ultrasonic range, I cranked 
up the sample rate to 96 kHz (although whether or 
not my laptop microphone can actually detect sound 
above 22 kHz is questionable) and stared at it in Au- 
dacity's spectrogram mode. Although I saw a few 
splotches at the top of the audible range, playing 
them back did not trigger the Z-Ring at all. How- 
ever, playing back the whole recording did. I tried 
playing subsets of the sample until I found portions 
that triggered the Z-Ring. As I kept cropping the 
audio shorter and shorter, I finally found what I was 
looking for. The trigger wasn't ultrasonic. It was in 
fact completely audible. 


When you activate a Z-Power in the game, a 
short little jingle always plays. I had previously as- 
sumed that the jingle was just for flavor, but when 
I looked at it, there were several distinctive lines 
on the spectrogram. The very beginning of the jin- 
gle included seven different tones, so I tried playing 
back that section. Sure enough, the Z-Ring acti- 
vated. I cropped it down to the first four tones, 
and the Z-Ring would reliably activate and play a 
specific sample whenever I played the audio back. 
Rearranging the tones, I got it to play back a dif- 
ferent sample. That was how to signal the toy, but 
now the task was finding all of the samples stored 
on the Z-Ring without dumping the ROM. 


Looking at the recording in the spectrogram, it 
was pretty clear that the first tone, which lasts all 
of 40 milliseconds and is a few hundred hertz lower 
than the rest of the signal, is a marker indicating 
that the next few tones describe which sample to 
play back. I quickly reconstructed the four tones 
as just sine waves in Audacity to test my hypothe- 
sis, and sure enough, I was able to trigger the tones 
using the constructed signal as well. However, that 
was a tedious process and did not lend itself to being 
able to explore and document all of the tone combi- 
nations. I knew I needed to write some software to 
help me quickly change the tones, so I could docu- 
ment all the combinations. Since it looked as if the 
signal was various combinations of approximately 
four different frequencies, it would take some explo- 
ration to get everything. 





I'm lazy and didn't feel like writing a tone gen- 
erator and hooking it up to an audio output de- 
vice and going through all of the steps I'd need to 
get sine waves of programmatically-defined frequen- 
cies to come out of my computer. However, I'm a 
special kind of lazy, and I really appreciate irony. 
The game is for the 3DS, right? What system is 


Pokémon famous for originating on? The original 
Game Boy, a platform with hardware for generating 
audible tones! Whereas the 3DS also has a micro- 
phone, the audio communication is only used in one 
direction. Perfect! 

Now, I'd never written a program for the Game 
Boy, but I had implemented a Game Boy emula- 
tor. Fixing bugs on an emulator requires debug- 
ging both the emulator and the emulated software at 
the same time, so I’m quite familiar with the Game 
Boy’s unique variant of Z80, making the barrier of 
entry significantly lower than I thought it would be. 
I installed Rednex GameBoy Development System,? 
one of the two most popular toolchains for compil- 
ing Game Boy homebrew ROMs, and wrote a few 
hundred lines of assembly. I figured the Game Boy’s 
audio channel 3, which uses 32-sample wavetables of 
four-bit audio, would be my best chance to approx- 
imate a sine wave. After a bit of experimenting, I 
managed to get it to create the right tones. But the 
first obstacle to playing back these tones properly 
was the timing. The first tone plays for 40 millisec- 
onds, and the remaining tones each last 20 millisec- 
onds. A frame on the GB is roughly 16 milliseconds 
long, so I couldn’t synchronize on frame boundaries, 
yet I found a busy loop to be impractical. (Yes, GB 
games often use busy loops for timing-sensitive op- 
erations.) Fortunately, the GB has a built-in timer 
that can fire an interrupt after a given number of 
cycles, so, after a bit of math, I managed to get the 
timing right. Success! I could play back a series of 
tones from a table in RAM with the right timing 
and the right frequencies. 





5 kHz 


0 kHz 


Sunzip pocorgtfoi4.pdf rgbds.zip 


Sure enough, when I played this back in an em- 
ulator, the Z-Ring activated! The ROM plays the 
tones upon boot and had no user interface for config- 
uring which tones to play, but recompiling the ROM 
was fast enough that it wasn’t really an issue. 


The natural next step was uploading the pro- 
gram to a real Game Boy. I quickly installed the 
program onto a flash cart that I had purchased while 
developing the emulator. I booted up my original 
Game Boy, the tones played, and... the Z-Ring did 
not activate. No matter how many times I restarted 
the program, the tones would not activate the Z- 
Ring. I recorded the audio it was playing, and 
the tones were right. I was utterly confused until 
I looked a bit closer at the recording: the signal 
was getting quieter with every subsequent tone. I 
thought that this must be a bug in the hardware, as 
the Game Boy’s audio hardware is notorious for hav- 
ing different quirks between models and even CPU 
revisions. I tried turning off the audio channel and 
turning it back on again a few cycles later to see if 
that fixed anything. It still worked in the emulator, 
so I put it back on the flash cart, and this time it 
worked! I could consistently trigger one of the sam- 
ples I’d seen, but some of the other ones seemed to 
randomly select one of three tones to play. Some- 
thing wasn't quite right with my tone generation, so 
I decided to halve the sample period, which would 
give me more leeway to finely adjust the frequency. 
This didn't appear to help at all, unfortunately. 
Scoping out all of the combinations of the tones I 
thought were in range yielded about 30 responses 
out of the 64 combinations I tried. Unfortunately, 
many of the responses appeared to be the same, and 
many of them weren't consistent. Additionally, sam- 
ples I knew the Z-Ring had were not triggered by 
any of these combinations. Clearly something was 
wrong. 


I needed a source of several unique known-good 
signals, so I scoured YouTube and found an “All Z- 
Moves" video. Sure enough, it triggered from the 
Z-Ring a bunch of reactions I hadn't seen yet. Tak- 
ing a closer look, I saw that the signal was actually 
all seven tones (not four), so extending the program 
to use seven tones suddenly yielded much more con- 
sistent results. Great! The bad news was that be- 
yond the first, fixed tone, there were four variations 
of each subsequent tone, leading to a total of 4? 
combinations. That's 4,096. That's a lot to scope 
out. I decided to take another route and catalog ev- 


ery signal in the video as a known pattern. I could 
try other signals later. Slowly, I went through the 
video and found every trigger. It seemed that there 
were two separate commands per move: one was for 
the initial half of the scene, where the Pokémon is 
“surrounded by Z-Power,” and then the actual Z- 
Move was a separate signal. Unfortunately, three of 
the former signals had been unintentionally cropped 
from the video, leaving me with holes in my data. 
Sitting back and looking at the data, I started notic- 
ing patterns. I had numbered each tone from 0 (the 
lowest) to 3 (the highest), and every single one of 
the first 15 signals (one for each of the 18 Pokémon 
types in-game, minus the three missing types) ended 
with a 3. Some of the latter 18 (the associated Z- 
Powers per type) ended with a 1, but most ended 
with a 3. I wasn’t quite sure what that meant until 
I saw that other tones were either a 0 or a 2, and the 
remainder were either a 1 or a 3. Each tone encoded 
only one bit, and they were staggered to make sure 
the adjacent bits were differentiable! 

This reduced the number of possibilities from 
over four thousand to a more manageable sixty-four. 
It also lent itself to an easy sorting technique, with 
the last bit being MSB and the first being LSB. As I 
sorted the data, I noticed that the first 18 fell neatly 
into the in-game type ordering, leaving three holes 
for the missing types, and the next 18 all sorted 
identically. This let me fill in the holes and left 
me with 36 of the 64 combinations already filled in. 
I also found 11 special, Pokémon-specific (instead 
of type-specific) Z-Moves, giving me 47 total signals 
and 17 holes left. As I explored the remaining holes, 
I found five audio samples of Pikachu saying differ- 
ent things, and the other 12 didn’t correspond to 
anything I recognized. 








In the process, I added a basic user interface to 
the Game Boy program that lets you either select 
from the presets or set the tones manually. Given 
the naming scheme of these Z-Crystals (for any given 
type or Pokémon, it would basically just be Typium- 
Z, e.g. Fire becomes Firium-Z), I naturally decided 
to name it Phreakium-Z.^ 


I thought I had found all of the Z-Ring's sound 
triggers, but it was pointed out to me while I was 
preparing to publish my results that the official 
soundtrack release had six “Z-Ring Synchronized” 
tracks that interfaced with the Z-Ring. I had al- 
ready purchased the soundtrack, so I took a look 
and tried playing back the tracks with the Z-Ring 
nearby. Nothing happened. More importantly, the 
distinctive jingle of the 5 kHz tones was completely 
absent from the tracks. So what was I missing? I 
tried switching it from Mode I into Mode II, and the 
Z-Ring lit up, perfectly synchronizing with the mu- 
sic. But where were the triggers? There was noth- 
ing visible in the 4-6 kHz range this time around. 
Although I could clip portions of tracks down to spe- 
cific triggers, I couldn't see anything in the spectro- 
gram until I expanded the visible range all the way 
up to 20 kHz. This time the triggers were indeed 
ultrasonic or very nearly so. 








Human hearing caps out at approximately 
20 kHz, but most adults can only hear up to about 
15 kHz. The sample rates of sound devices are typ- 
ically no greater than 48 kHz, allowing the produc- 
tion of frequencies up to 24 kHz, including only a 
narrow band of ultrasonic frequencies. Given the 
generally poor quality of speakers at extremely high 
frequencies, you can imagine my surprise when I saw 
a very clear signal at around 19 kHz. 


^git clone https://github.com/endrift/phreakium-z; unzip pocorgtfoi4.pdf phreakium-z.zip 
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Deinem Handgelenk superior de Z-Rin 
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E Bh 2x AAA 15V (LRO3) 
“BATTERIES INCLUDED + PILES INCLUSES 
BATTERIEN INKLUSIVE * PILAS INCLUIDAS 


BATTERIE INCLUSE - INCLUSIEF BATTERIJEN 
-PILHAS INCLUÍDAS 





Zooming in, I saw the distinctive pattern of a 
lower, longer initial tone followed by several stag- 
gered data tones. However, this time it was a 9-bit 
signal, with a 60 ms initial tone at exactly 18.5 kHz 
and a 20 ms gap between the bits. Unfortunately, 
18 kHz is well above the point at which I can get any 
fine adjustments in the Game Boy’s audio output, so 
I needed to shift gears and actually write something 
for the computer. At first I wrote something quick in 
Rust, but this proved to be a bit tedious. I realized 
I could make something quite a bit more portable: 
a JavaScript web interface using WebAudio.? 

After narrowing down the exact frequencies used 
in the tones and debugging the JavaScript (as it 
turns out, l've gotten quite rusty), I whipped up 
a quick interface that I could use to explore com- 
mands. After all, 512 commands is quite a bit more 
than the 64 from Mode I. 

Despite being a larger number of combinations, 
512 was still a reasonable number to explore in a 
few hours. After I got the WebAudio version work- 
ing consistently, I added the ability to take a num- 
ber from 0 to 511 and output the correspondingly 
indexed tone, and I began documenting the individ- 
ual responses generated. At first I was getting oddly 
erratic sequences, until I realized that I was parsing 
a base 10 number as a base 16 index. With that 
fixed, everything fell into place. I noticed that the 
first 64 indices of the 512 were in fact identical to 
the 64 Mode I tones, so that was quick to document. 
Once I got past the initial 64, I noticed that the re- 
sponses from the Z-Ring no longer corresponded to 
game actions but were instead more granular single 
actions. For example, instead of a sequence of vi- 





brations and light colors that corresponded to the 
animation of a Z-Move in game, a response included 
only one sound effect coupled with one lighting ef- 
fect or one lighting effect with one vibration effect. 
There was also a series of sound effects that did not 
appear in Mode I and that seemed to be linked to 
individual Pokémon types. Many of the responses 
seemed randomly ordered, almost as though the de- 
velopers had added the commands ad hoc without 
realizing that ordering similar responses would be 
sensible. Huge swaths of the command set ended 
up being the Cartesian product of a light color with 
a vibration effect. This ended up being enough of 
the command set that I was able to document the 
remainder of the commands within only a handful 
of hours. 


Most of the individual commands weren’t inter- 
esting, but I did find eight additional Pikachu voice 
samples and a rather interesting command that — 
when played two or three times in a row — kicked the 
Z-Ring into what appeared to be a diagnostic mode. 
It performed a series of vibrations followed by a se- 
ries of tones unique to this response, after which the 
Z-Ring stopped responding to commands. After a 
few seconds, the light on the bottom, which is com- 
pletely undocumented in the manual and had not il- 
luminated before, started blinking, and the light on 
top turned red. However, it still didn’t respond to 
any commands. Eventually I discovered that switch- 
ing it to the neutral mode would change the light to 
blue for a few seconds, and then the toy would re- 
vert to a usable state. I’m still unsure of whether 
this was a diagnostic mode, a program upload mode, 
or something completely different. 





By this point I’d put in several hours over a 
few days into figuring out every nook and cranny of 
this device. Having become bored with it, I decided 
to bite the bullet and disassemble the hardware. I 
found inside a speaker, a microphone, a motor with a 
lopsided weight for generating the vibrations, and a 
PCB. The PCB, although rather densely populated, 
did not contain many interesting components other 
than an epoxy blob labeled U1, an MX25L8006E 
flash chip labeled U2, and some test points. You 
will find a dump of this ROM attached.® At this 
point, I decided to call it a week and put the Z-Ring 
back together; it was just a novelty, after all. 


?git clone https://github.com/endrift/phreakium-js; unzip pocorgtfoi4.pdf phreakium-js.html 


Sunzip pocorgtfoi4.pdf zring-flash.bin 





These are the 512 commands of the Z-Ring. 


000: 
001: 
002: 
003: 
004: 
005: 
006: 
007: 
008: 
009: 
00A: 
OOB: 
00C: 
OOD: 
OOE: 
OOF: 
010: 
O11: 
012: 
013: 
014: 
O15: 
016: 
017: 
018: 
019: 
01A: 
O1B: 
01C: 
01D: 
O1E: 
O1F: 
020: 
021: 
022: 
023: 
024: 
025: 
026: 
027: 
028: 
029: 
02A: 
O2B: 
02C: 
02D: 
02E: 
O2F: 
030: 
031: 
032: 
033: 
034: 
035: 
036: 
037: 
038: 
039: 
03A: 
03B: 
03C: 
03D: 
OSE: 
O3F: 
040: 
041: 
042: 
043: 
044: 


Normalium-Z 

Firium-Z 

Waterium-Z 

Grassium-Z 

Electrium-Z 

Icium-Z 

Fightium-Z 

Poisonium-Z 

Groundium-Z 

Flyium-Z 

Psychium-Z 

Buginium-Z 

Rockium-Z 

Ghostium-Z 

Dragonium-Z 

Darkium-Z 

Steelium-Z 

Fairium-Z 

Breakneck Blitz 

Inferno Overdrive 

Hydro Vortex 

Bloom Doom 

Gigavolt Havoc 

Subzero Slammer 

All-Out Pummeling 

Acid Downpour 

Tectonic Rage 

Supersonic Skystrike 

Shattered Psyche 

Savage Spin-Out 

Continental Crush 

Never-Ending Nightmare 

Devastating Drake 

Black Hole Eclipse 

Corkscrew Crash 

Twinkle Tackle 

Sinister Arrow Raid (Decidium-Z) 

Malicious Moonsault (Incinium-Z) 

Oceanic Operetta (Primarium-Z) 
Catastropika (Pikachunium-Z) 

Guardian of Alola (Tapunium-Z) 

Stoked Sparksurfer (Aloraichium-Z) 
Pulverizing Pancake (Snorlium-Z) 

Extreme Evoboost (Eevium-Z) 

Genesis Supernova (Mewium-Z) 

Soul-Stealing 7-Star Strike (Marshadium-Z) 
(unknown) 

(unknown) 

10,000,000 Volt Thunderbolt (Pikashunium-Z) 
(unknown) 

(unknown) 

(unknown) 

(unknown) 

(unknown) 

(unknown) 

(unknown) 

(unknown) 

Pikachu 1 

Pikachu 
Pikachu 
Pikachu 
Pikachu 
(unknown) 

(no response) 
SFX/Light (Normal) 
SFX/Light (Fire) 
SFX/Light (Water) 
SFX/Light (Grass) 
SFX/Light (Electric) 


oP WD 





SS 


045: 
046: 
047: 
048: 
049: 
04A: 
O4B: 
04C: 
04D: 
04E: 
04F: 
050: 
051: 
052: 
053: 
054: 
055: 
056: 
057: 
058: 
059: 
O54: 
OBB: 
05C: 
O5D: 
OBE: 
OBF: 
060: 
061: 
062: 
063: 
064: 
065: 
066: 
067: 
068: 
069: 
06A: 
06B: 
06C: 
O6D: 
O6E: 
O6F: 
070: 
O71: 
072: 
073: 
074: 
075: 
076: 
O77: 
078: 
079: 
O7A: 
O7B: 
O7C: 
07D: 
O7E: 
O7F: 
080: 
081: 
082: 
083: 
084: 
085: 
086: 
087: 
088: 
089: 


SFX/Light 
SFX/Light 
SFX/Light 
SFX/Light 
SFX/Light 
SFX/Light 
SFX/Light 
SFX/Light 
SFX/Light 
SFX/Light 


(Ice) 
(Fighting) 
(Poison) 
(Ground) 
(Flying) 
(Psychic) 
(Bug) 
(Rock) 
(Ghost) 
(Dragon) 


SFX/Light (Dark) 

SFX/Light (Steel) 

SFX/Light (Fairy) 

(no response) 

Vibration (soft, short) 
Vibration (soft, medium) 
Vibration (pattern 1) 
Vibration (pattern 2) 
Vibration (pattern 3) 
Vibration (pattern 4) 
Vibration (pattern 5) 
Vibration (pattern 6) 
Vibration (pattern 7) 
Vibration (pattern 8) 
Vibration (pattern 8) 
Vibration (pattern 9) 
Vibration (pattern 10) 
Vibration (pattern 11) 
Vibration (pattern 12) 
Vibration (pattern 13) 
Vibration (pattern 14) 

Light (yellow) 

Light (pale blue) 

Light (white) 

Light (pattern 1) 

Light (pattern 2) 

Vibration (pattern 15) 
Vibration (pattern 16) 
Light/Vibration (red, very short) 
Light/Vibration (red, short) 
Light/Vibration (red, medium) 
Light (red) 

Light (yellow/green) 

Light (green) 

Light (blue) 

Light (purple) 

Light (pale purple) 

Light (magenta) 

Light (pale green) 

Light (cyan) 

Light (pale blue/purple) 
Light (gray) 

Light (pattern purple, pale purple) 
Light/Vibration (pale yellow, short) 
Light/Vibration (pale yellow, short) 
(no response) 

(no response) 

Self test/program mode? (reboots afterwards) 
Light (pale yellow) 

Light (pale blue) 

Light (pale magenta) 
SFX/Vibration (Normal) 
SFX/Vibration (Fire) 
SFX/Vibration (Water) 
SFX/Vibration (Grass) 
SFX/Vibration (Electric) 
SFX/Vibration (Ice) 
SFX/Vibration (Fighting) 
SFX/Vibration (Poison) 


08A: 
O8B: 
08C: 
08D: 
O8E: 
O8F: 
090: 
091: 
092: 
093: 
094: 
095: 
096: 
097: 
098: 
099: 
09A: 
O9B: 
09C: 
O9D: 
O9E: 
O9F: 
OAO: 
OA1: 
OA2: 
OA3: 
OA4: 
OA5: 
0A6: 
OAT: 
0A8: 
049: 
OAA: 
OAB: 
OAC: 
OAD: 
OAE: 
OAF: 
OBO: 
OB1: 
OB2: 
OB3: 
OB4: 
OB5: 
OB6: 
OB7: 
OB8: 
OB9: 
OBA: 
OBB: 
OBC: 
OBD: 
OBE: 
OBF: 
oco: 
OC1: 
0C2: 
0C3: 
OCA: 
OC5: 
OC6: 
OC7: 
0C8: 
OC9: 
OCA: 
OCB: 
OCC: 
OCD: 
OCE: 


SFX/Vibration (Ground) 
SFX/Vibration (Flying) 
SFX/Vibration (Psychic) 
SFX/Vibration (Bug) 
SFX/Vibration (Rock) 
SFX/Vibration (Ghost) 
SFX/Vibration (Dragon) 
SFX/Vibration (Dark) 
SFX/Vibration (Steel) 
SFX/Vibration (Fairy) 

Pikachu 1 

Pikachu 2 

Pikachu 3 

Pikachu 4 

Pikachu 5 

Vibration (speed 1, hard, 2x) 
Vibration (speed 1, hard, 4x) 
Vibration (speed 1, hard, 8x) 
Vibration (speed 1, hard, 16x) 
Vibration (speed 1, pattern, 2x) 
Vibration (speed 1, pattern, 4x) 
Vibration (speed 1, pattern, 8x) 
Vibration (speed 1, pattern, 16x) 
Vibration (speed 2, hard, 2x) 
Vibration (speed 2, hard, 4x) 
Vibration (speed 2, hard, 8x) 
Vibration (speed 2, hard, 16x) 
Vibration (speed 2, pattern, 2x) 
Vibration (speed 2, pattern, 4x) 
Vibration (speed 2, pattern, 8x) 
Vibration (speed 2, pattern, 16x) 
Vibration (speed 3, hard, 2x) 
Vibration (speed 3, hard, 4x) 
Vibration (speed 3, hard, 8x) 
Vibration (speed 3, hard, 16x) 
Vibration (speed 3, pattern, 2x) 
Vibration (speed 3, pattern, 4x) 
Vibration (speed 3, pattern, 8x) 
Vibration (speed 3, pattern, 16x) 
Vibration (speed 4, hard, 2x) 
Vibration (speed 4, hard, 4x) 
Vibration (speed 4, hard, 8x) 
Vibration (speed 4, hard, 16x) 
Vibration (speed 4, pattern, 2x) 
Vibration (speed 4, pattern, 4x) 
Vibration (speed 4, pattern, 8x) 
Vibration (speed 4, pattern, 16x) 
Vibration (speed 5, hard, 2x) 
Vibration (speed 5, hard, 4x) 
Vibration (speed 5, hard, 8x) 
Vibration (speed 5, hard, 16x) 
Vibration (speed 5, pattern, 2x) 
Vibration (speed 5, pattern, 4x) 
Vibration (speed 5, pattern, 8x) 
Vibration (speed 6, hard, 16x) 
Vibration (speed 6, hard, 2x) 
Vibration (speed 6, hard, 4x) 
Vibration (speed 6, hard, 8x) 
Vibration (speed 6, hard, 16x) 
Vibration (speed 6, pattern, 2x) 
Vibration (speed 6, pattern, 4x) 
Vibration (speed 6, pattern, 8x) 
Vibration (speed 6, pattern, 16x) 
Vibration (speed 7, hard, 2x) 
Vibration (speed 7, hard, 4x) 
Vibration (speed 7, hard, 8x) 
Vibration (speed 7, hard, 16x) 
Vibration (speed 7, pattern, 2x) 
Vibration (speed 7, pattern, 4x) 


AL MUSIC BOXES | 


HIGHEST AWARD. 


MEDAL AND DIPLOMA AT THE 
COLUMBIAN EXPOSITION. 


IDEAL MUSICAL BOXES 


are the most com- 


plete, durable and perfect boxes made, produce the 
most exquisite music and will play any number 


of tunes. 


We have in stock 21 different styles from $70.00 up. 
These instruments are all guaranteed. Alsoa 
complete line of musical boxes of all styles and sizes, 
from 40 cts. to $1,500, and a line of musical novelties. 

Send 4-cent stamp for 65-page illustrated cata- 


logue with list of tunes. 


JACOT & SON, 39 Union Sq. W 
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OCF: 
ODO: 
OD1: 
OD2: 
OD3: 
OD4: 
OD5: 
OD6: 
OD7: 
OD8: 
OD9: 
ODA: 
ODB: 
ODC: 
ODD: 
ODE: 
ODF: 
OEO: 
OE1: 
OE2: 
OE3: 
OE4: 
OES: 
OE6: 
OE7: 
OE8: 
OE9: 
OEA: 
OEB: 
OEC: 
OED: 
OEE: 
OEF: 
OFO: 
OF 1: 
OF2: 
OF3: 
OF4: 
OF5: 
OF6: 
OF7: 
OF8: 
OF9: 
OFA: 
OFB: 
OFC: 
OFD: 
OFE: 
OFF: 
100: 
101: 
102: 
103: 
104: 
105: 
106: 
107: 
108: 
109: 
10A: 
10B: 
10C: 
10D: 
10E: 
10F: 
110: 
111: 
112: 
113: 
114: 
115: 
116: 
117: 
118: 
119: 
11A: 
11B: 
11C: 
11D: 
11E: 
11F: 
120: 
121: 
122: 
123: 
124: 
125: 
126: 
127: 
128: 
129: 
12A: 
12B: 
12C: 
12D: 
12E: 
12F: 
130: 
131: 
132: 
133: 
134: 


Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 


(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
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pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 
pattern, 2x) 
pattern, 4x) 
pattern, 8x) 
pattern, 16x) 
hard, 2x) 
hard, 4x) 
hard, 8x) 
hard, 16x) 


135: 
136: 
137: 
138: 
139: 
13A: 
13B: 
13C: 
13D: 
13E: 
13F: 
140: 
141: 
142: 
143: 
144: 
145: 
146: 
147: 
148: 
149: 
14A: 
14B: 
14C: 
14D: 
14E: 
14F: 
150: 
151: 
152: 
153: 
154: 
155: 
156: 
157: 
158: 
159: 
15A: 
15B: 
15C: 
15D: 
15E: 
15F: 
160: 
161: 
162: 
163: 
164: 
165: 
166: 
167: 
168: 
169: 
16A: 
16B: 
16C: 
16D: 
16E: 
16F: 
170: 
171: 
172: 
173: 
174: 
175: 
176: 
177: 
178: 
179: 
17A: 
17B: 
17C: 
17D: 
17E: 
17F: 
180: 
181: 
182: 
183: 
184: 
185: 
186: 
187: 
188: 
189: 
18A: 
18B: 
18C: 
18D: 
18E: 
18F: 
190: 
191: 
192: 
193: 
194: 
195: 
196: 
197: 
198: 
199: 
19A: 


Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 
Vibration 


(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 
(speed 


Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (speed 
Vibration (soft, 
Pikachu 6 

Pikachu 7 

Pikachu 8 

Pikachu 9 

Pikachu 10 

Pikachu 11 

Pikachu 12 

Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Pikachu 13 


20, pattern, 2 
20, pattern, 4 
20, pattern, 8 
20, pattern, 1 
21, hard, 2x) 
21, hard, 4x) 
21, hard, 8x) 
21, hard, 16x) 
21, pattern, 2 
21, pattern, 4 
21, pattern, 
21, pattern, 
22, hard, 2x) 
22, hard, 4x) 
22, hard, 8x) 
22, hard, 16x 
22, pattern, 
22, pattern, 
22, pattern, 
22, pattern, 
very long) 


(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 
(red, pattern 


Light (pale magenta) 
Vibration (pattern 15) 


Light/Vibration 


(pattern) 


Light (pale yellow/green) 
Light (pale blue/purple) 


Light (magenta) 


Light (yellow/green) 


Light (cyan) 


Light (pale blue) 


Light (very pale 


blue) 


Light (pale magenta) 
Light (pale yellow) 


Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 


(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(blue, pattern 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(green, patter 
(yellow/green, 
(yellow/green, 
(yellow/green, 
(yellow/green, 
(yellow/green, 
(yellow/green, 
(yellow/green, 
(yellow/green, 
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x) 
x) 
x) 
6x) 


x) 
x) 


8x) 
16x) 


) 
2x) 
Ax) 
8x) 
16x) 


1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 
9) 
10) 
11) 
12) 
13) 
14) 
15) 
16) 
17) 


1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 
9) 
10) 
11) 
12) 
13) 
14) 
15) 
16) 
17) 
18) 

n 1) 

n 2) 

n 3) 

n 4) 

n 5) 

n 6) 

n 7) 

n 8) 

n 9) 

n 10) 

n 11) 

n 12) 

n 13) 

n 14) 

n 15) 

n 16) 

n 17) 

n 18) 
pattern 
pattern 
pattern 
pattern 
pattern 
pattern 
pattern 
pattern 


1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 


19B: 
19C: 
19D: 
19E: 
19F: 
140: 
141: 
142: 
143: 
144: 
145: 
146: 
147: 
148: 
149: 
1AA: 
14B: 
1AC: 
1AD: 
1AE: 
1AF: 
1BO: 
1B1: 
1B2: 
1B3: 
1B4: 
1B5: 
1B6: 
1B7: 
1B8: 
1B9: 
1BA: 
1BB: 
1BC: 
1BD: 
1BE: 
1BF: 
1CO: 
1C1: 
1C2: 
1C3: 
1C4: 
1C5b: 
1C6: 
1C7: 
1C8: 
1C9: 
1CA: 
1CB: 
1CC: 
1CD: 
1CE: 
1CF: 
1DO: 
1D1: 
1D2: 
1D3: 
1D4: 
1D5: 
1D6: 
1D7: 
1D8: 
1D9: 
1DA: 
1DB: 
1DC: 
1DD: 
1DE: 
1DF: 
1E0: 
1E1: 
1E2: 
1E3: 
1E4: 
1E5: 
1E6: 
1E7: 
1E8: 
1E9: 
1EA: 
1EB: 
1EC: 
1ED: 
1EE: 
1EF: 
1FO: 
1F1: 
1F2: 
1F3: 
1F4: 
1F5: 
1F6: 
1F7: 
1F8: 
1F9: 
1FA: 
1FB: 
1FC: 
1FD: 
1FE: 
1FF: 


Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 
Light/Vibration 


(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 
(yellow/green, pattern 


(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(purple, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(yellow, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(white, pattern 
(red, medium) 


(yellow/green, medium) 


(green, medium) 
(blue, very shor 
(blue, short) 
(blue, medium) 
(green, very sho 
(green, short) 
(green, medium) 


1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 
9) 
10) 
11) 
12) 
13) 
14) 
15) 
16) 
17) 
18) 
1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 
9) 
10) 
11) 
12) 
13) 
14) 
15) 
16) 
17) 
18) 
1) 
2) 
3) 
4) 
5) 
6) 
7) 
8) 
9) 
10) 
11) 
12) 
13) 
14) 
15) 
16) 
17) 
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t) 


rt) 


9) 

10) 
11) 
12) 
13) 
14) 
15) 
16) 
17) 
18) 


(yellow/green, very short) 


(yellow/green, short) 
(yellow/green, medium) 


(purple, very sh 
(purple, short) 
(purple, medium) 
(yellow, very sh 
(yellow, short) 
(yellow, medium) 
(white, very sho 
(white, short) 
(white, medium) 
(red, pattern 18 


Light (red, indefinite) 
Light (yellow, indefinite) 
Light (green, indefinite) 
Light (blue, indefinite) 
Light (purple, indefinite) 
Light (pattern, indefinite) 
SFX/Light (sparkle, gray) 


(turn off light) 


Light/Vibration 


Light/Vibration (pale purple, medium) 


(blue, medium) 


ort) 


ort) 


rt) 


) 


Light/Vibration (pattern, medium) 


(no response) 
(no response) 
(no response) 
(no response) 


14:03 Concerning Desert Studies, Cyberwar, and the Desert Power 


Gather round, neighbors, as we close the mois- 
ture seals and relax the water discipline. ‘Take off 
your face masks and breathe the sietch air freely. It 
is time for a story of the things that were and the 
things that will come. 

Knowledge and water. These are the things that 
rule the universe. ‘They are alike—and one truly 
needs to lack them to appreciate their worth. ‘Those 
who have them in abundance proclaim their value— 
and waste them thoughtlessly, without a care. They 
make sure their wealth and their education degrees 
are on display for the world, and ever so hard to 
miss; they waste both time and water to put us in 
our place. Yet were they to see just one of our hid- 
den caches, they would realize how silly their dis- 
plays are in comparison. 

For while they pour out the water and the time 
of their lives, and treat us as savages and dismiss us, 
we are working to change the face of the world. 
































by Naib Manul Laphroaig’ 


Their scientists have imperial ranks, and their 
city schools teach—before and above any useful 
subject—respect for these ranks and for those who 
pose as “scientists” on the imperial TV. And yet, 
guess who knows more physics, biology, and plane- 
tary ecology that matters. Guess who knows how 
their systems actually work, from the smallest wa- 
ter valve in a stillsuit to the ecosystems of an entire 
planet. They mock Shai-hulud and dismiss us Fre- 
men as the unwashed rabble tinkering to survive in 
the desert—yet their degrees don’t impress the sand. 














The works of the ignorant are like sand. When 
yet sparse, they merely vex and irritate like loose 
grains; when abundant, they become like dunes that 
overwhelm all water, life, and knowledge. Verily, 
these are the dunes where knowledge goes to die. 
As the ignorant labor, sand multiplies, until it cov- 
ers the face of the world and pervades every breath 
of the wind. 

And then there was a Dr. Kynes. To imperial 
paymasters, he was just another official on the long 
roll getting ever longer. To the people of the city he 
was just another bureaucrat to avoid if they could, 
or to bribe if they couldn’t. To his fellow civil 
servants—who considered themselves scholars, yet 
spent more time over paperwork than most clerks— 
he was an odd case carrying on about things that 
mattered nothing to one’s career, as absolutely ev- 
erybody knew; in short, they only listened to him if 
they felt charitable at the moment. 











For all these alleged experts, the order of life 
was already scientifically organized about the best 
it could be. One would succeed by improving the 
standard model of a stillsuit, or just as well by sell- 
ing a lot of crappy ones. 

One did not succeed by talking about chang- 
ing a planet. Planets were already as organized as 
they could be. A paper could be written, of course, 
but, to be published, the paper had to have both 
neatly tabulated results and a summary of prior 
work. There was no prior published work on chang- 
ing planets, no journals devoted to it, and no out- 
standing funding solicitations. One would not even 
get invited to lecture about it. It was a waste of 


TNaib Laphroiag, an early follower of Muad’dib, is sometimes incorrectly said to have composed the Litany against Cyber 
(“I shall not cyber. Cyber is the mind-killer that brings bullshit. I will face cyber and let it pass over me. When the bullshit 
has gone, only PoC of how nifty things really work will remain.”) It had, in fact, originated with early Butlerians, but the 
Naib carried it to neighbors far and wide over the sand wherever it needed to be heard. 


12 


time, useless for advancement in rank. 

Besides, highly ranked minds must have already 
thought about it, and did not take it up; clearly, the 
problem was intractable. Indeed, weren’t there al- 
ready dissertations on the hundred different aspects 
of sand, and of desert plants, and of the native ani- 
mals and birds? There were even some on the silly 
native myths. Getting on the bad side of the water- 
sellers, considering how much they were donating 
to the cause of higher learning, was also not a wise 
move. 

But Kynes knew a secret: knowledge was wa- 
ter, and water was knowledge. The point of knowl- 
edge was to provide what was needed the most, not 
ranks or lectures. And he knew another secret: one 
could, in fact, figure out a thing that many superior 
minds hadn’t bothered with, be it even the size of 
the planet. And he may have guessed a third se- 
cret: if someone didn’t value water as life, there was 
no point of talking to them about water, or about 
knowledge. They would, at best, nod, and then go 
about their business. It is like spilling water on the 
sand. 

That did not leave Kynes with a lot of options. 
In fact, it left him with none at all. And so he did a 
thing that no one else had done before: he left the 
city and walked out onto the sand. He went to find 
us, and he became Liet. 

For those who live on the sand and are sur- 
rounded by it understand the true value of water, 
and of figuring things out, be they small or large. 
This Kynes sought, and this he found—with us, the 
Fremen. 

His manner was odd to us, but he knew things of 
the sand that no city folk cared to know; he spoke 
of water in the sand as we heard none speak before. 








He must have figured it out—and there were just 
enough of us who knew that figuring things out was 
water and life. And so he became Liet. 





His knowledge, rejected by bureaucrats, already 
turned into a water wealth no bureaucrat can yet 
conceive of. His peers wrote hundreds of thousands 
of papers since he left, and went on to higher ranks— 
and all of these will be blown away by the desert 
winds. A lot of useless technology will be sold and 
ground into dust on the sand—while Liet’s words are 
changing the desert slowly but surely. 


Something strange has been going of late in their 
sheltered cities. There is talk of a “sand-war,” and 
of “sand warriors,” and of “sand power.” ‘They are 
giving sand new names, and new certifications of 
“desert moisture security professionals” to their city 
plumbers. ‘Their schools are now supposed to teach 
something they called SANDS, “Science, Agronomy, 
Nomenclature,? Desert Studies,” to deliver a “sand 
superiority.” Their imperial news spread rumors 
of “anonymous senior imperial officials” unleashing 
"sand operations,” the houses major building up 
their “sand forces" and the houses minor demand- 
ing an investigation in the Landsraat. 


Little do they know where the true sand power 
lies, and where the actual water and knowledge are 
being accumulated to transform the desert. 


The sand will laugh at them—and one day the 
one who understands the true source of power will 
come after Liet, the stored water will come forth, 
the ecology will change—and a rain will fall. 


Until then, we will keep the water and the knowl- 
edge. Until then, we, the Fremen, will train the new 
generations of those who know and those who figure 
things out! 





8Truly, they believe that teaching and learning is repetition of words, and that their things break on the sand because they 
are named wrong. Change the words, and everything will work on the sand! Hear the sandstorm roaring with laughter above 


the dunes, and the great Shai-hulud writhing with it below! 
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14:04  Flush-- Reload 


Dear Editors and Readers of PoC||GTFO, 


You've been lied to about how your computer 
works. You see, in a programming class they teach 
you just enough for you to get on with your job and 
no more. What you learn is a mere abstraction of the 
very complicated piece of physics sitting under your 
desk. To use your computer to its fullest potential, 
you must forget the familiar abstraction and finally 
see your computer for what it really is. Come with 
me, as we take a small step towards enlightenment. 


You know what makes a computer—or so you 
think. There is a processor. There is a bank of main 
memory, which the processor reads, writes, and ex- 
ecutes from. And there are processes, those entities 
that from time to time get loaded into the processor 
to do their work. 


As we know, processes shouldn't be trusted to 
play well together, and need to be kept separate. 
Many of the processor's features were added to keep 
those processes isolated. It would be quite bad if 
one process could talk to another without the sys- 
tem administrator's permission. 


We also know that the faster a computer is, the 
more work it can do and the more useful it is. Even 
more features were introduced to the processor in 
order to make it go as fast as possible. 


Accordingly, your processor most likely has a 
memory cache sitting between main memory and 
the processor, remembering recently-read data and 
code, so that the next time the processor reads from 
the same address, it doesn't have to reach all the 
way out to main memory. The vendors will say this 
feature was added to make the processor go faster, 
and it does do a great job of that. But I will show 
you that the cache is also a feature to help hack- 
ers get around those annoying access controls that 
system administrators seem to love. 


What I'm going to do is show you how to send 
a text message from one process to the other, using 
only memory reads. What!? How could this be pos- 
sible? According to your programming class, you 
say, reads from memory are just reads, they can't 
be used to send messages! 


?Usenix Security 2014 
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The gist is this: the cache remembers recently 
executed code, which means that it must also re- 
member which code was recently executed. Pro- 
cesses are in control of the code they execute, so 
what we can do is execute a special pattern of code 
that the cache will remember. When the second 
process gets a chance to run, it will read the pattern 
out of the cache and recover the message. Oh how 
thoughtful it was of the processor designers to add 
this feature! 





The undocumented feature we'l be using is 
called “Flush+Reload,” and it was originally discov- 
ered by Yuval Yarom and Katrina Falkner.? It's 
available in most modern Intel processors, so if 
you've got one of those, you should be able to follow 
along. 
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It works like this. When Sally the Sender pro- 
cess gets loaded into memory, one copy of all her ex- 
ecuted code gets loaded into main memory. When 
Robert the Receiver process loads Sally’s binary into 
his address space, the operating system isn’t going 
to load a second copy: that would be wasteful. In- 
stead, it’s just going to point Robert’s page tables 
at Sally’s memory. If Sally and Robert could both 
write to the memory, it would be a huge problem 
since they could simply talk by writing messages to 
each other in the shared memory. But that isn’t a 
problem, because one of those processor security fea- 
tures stops both Sally and Robert from being able 
to write to the memory. How do they communicate 
then? 








When Sally the Sender executes some of her 
code, the cache—the last-level cache, to be specific— 
is going to remember her most recently executed 
code. When Robert the Receiver reads a chunk of 
code in Sally’s binary, the read operation is going to 
be sent through the very same cache. So: if Sally 
ran the code not too long ago, Robert’s read will 
happen very fast. If Sally hasn’t run the code in a 
while, Robert’s read is going to be slow. 








Sally and Robert are going to agree ahead of time 
on 27 locations in Sally’s binary. That’s one location 
for each letter of the alphabet, and one left over for 
the space character. To send a message to Robert, 
Sally is going to spell out the message by executing 
the code at the location for the letter she wants to 
send. Robert is going to continually read from all 27 
locations in a loop, and when one of them happens 
faster than usual, he'll know that's a letter Sally just 
sent. 


Figure 1 contains the source code for Sally's bi- 
nary. Notice that it doesn't even explicitly make 
any system calls. 


This program takes a message to send on the 
command-line and simply passes the processor’s 
thread of execution over the probe site correspond- 
ing to that character. To have Sally send the 
message “THE QUICK BROWN FOX JUMPS OVER THE 
LAZY DOG" we just compile it without optimizations, 
then run it. 


But how does Robert receive the message? 
Robert runs the program whose source code is at 
flush-reload/myversion. The key to that pro- 
gram is this bit of code, which times how long it 
takes to read from an address, and then flushes it 
from the cache. 
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| attribute — ((always inline)) 
inline unsigned long probe(char xadrs) { 
volatile unsigned long time; 


| | volatile ( 
mfence 
lfence 


$a 
\n" 
Vn" 
brad 
\n" 
Vn" 
\n" 
ii 
\n" 
Vn" 


rdtsc 
lfence 
movl %%eax , %Hesi 


movl (961), %%eax 
lfence 

rdtsc 

subl %Hesi , X%eax 
clflush 0(%1) 
"=a" (time) 
"c" (adrs) 

"Z esi " , "oed x" ) 


return time; 


By repeatedly running this code on those special 
probe sites in Sally's binary, Robert will see which 
letters Sally is sending. Robert just needs to know 
where those probe sites are. It's a matter of filter- 
ing the output of objdump to find those addresses, 
which can be done with this handy script: 





#!/ bin/bash 


for letter in {A..Z} 
do 
addr=$(objdump —D -M intel msg i 
sed —n —e "/<$letter >/,\$p" | \ 
grep call | head —n 1 E 
cut —d ’:’ —-f 1 | tr =d > 7); 
echo —n "—p $letter:Ox$addr " 
done 
addr=$(objdump -D -M intel msg | \ 
sed —n —e "/<SP>/,\$p" | \ 
grep call | head —n 1 |i. 3 
cut —d ’:’ —-f 1 | tr =d " 7); 


echo "—p _:0x$addr" 





Assuming this script works, it will output a list of 
command-line arguments for the receiver, enumerat- 
ing which addresses to watch for getting entered into 
the cache: 





0 x425ce5 
0x452d15 
0x47fd45 
Ox4acd75 
0x4d9da5 
0x506dd5 
0x533e05 
0x560e35 
:0x58de65 


:0x40'7cc5 
:0 x434cf5 


—p B:0x416cd5 —p 
—p E:0x443d05 —p 
:0x461d25 —p H:0x470d35 —p 
:0x48ed55 —p K:0x49dd65 —p 
:0x4bbd85 —p N:0x4cad95 
:0x4e8db5 —p Q:0x4f7dc5d 
:0x515de5 —p T:0x524df5 
:0x542e15 —p W:0x551e25 
:0x56fe45 —p Z:0x57ee55 


=P 
—P 
B 
=P 
—p | 


ie ee ee 


/* 


msg.c 


Send a message 


through t 


he 


Flush+Reload 
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#define PROBE null(); 
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Figure 1. Sally’s Executable 
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The letter before the colon is the name of the 
probe site, followed by the address to watch after 
the colon. With those addresses, Robert can run 
the tool and receive Sally’s messages. 


—t 120 —s 20000 


11$ ./spy —e ./msg 
:0x407cc5 —p 
:0x434cf5 —p 
0x461d25 —p 
0x48ed55 —p 
Ox4bbd85 —p 


B:0x416cd5 
E:0x443d05 
H:0x470d35 
K:0x49dd65 
N:0x4cad95 
—p Q:0x4f7dc5 
—p T:0x524df5 
—p W:0x551e25 
—p Z2:0x57ee55 


:0x425ce5 
:0x452d15 
:0x47fd45 
:0x4acd75 
:0x4d9da5 
:0x506dd5 
:0x533e05 
:0x560e35 
:0x58de65 


P 
=P 
=P 
—p 
=P 
=P 
=P 
=P 
—p 


0 x4e8db5 
0x515de5 
0x542e15 
0 x56fe45 


<K<nVEGAUS 
EO BP ee ee ee E a 


The -e option is the path to Sally’s binary, 
which must be exactly the same path as Sally ex- 
ecutes. The -t parameter is the threshold that de- 
cides what’s a fast access or not. If the memory read 
is faster than that many clock cycles, it will be con- 
sidered fast, which is to say that it’s in the cache. 
The -s option is how often in clock cycles to check 
all of the probes. 

With Robert now listening for Sally’s messages, 
Sally can run this command in another terminal as 
another user to transmit her message. 


$ ./msg "The quick brown fox jumps over the 
lazy dog" 








1 WARNING: This processor does not have an 
invariant TSC. 

Detected ELF type: Executable. 

3 TIH[E| |QJUJI]CJ|K| | |B|BIRJOIWIN| |FJO|X| | 

J|U|M|P|S| JO[|VIEJR| |T|H]E| |L|AIZIY] | 


D|O|G| 


There’s a bit of noise in the signal (note the repli- 
cated B’s), but it works! Don’t take my word for it, 
try it for yourself! It’s an eerie feeling to see one 
process send a message to another even though all 
they’re doing is reading from memory. 

Now you see what the cache really is. Not only 
does it make your computer go faster, it also has this 
handy feature that lets you send messages between 
processes without having to go through a system 
call. You’re one step closer to enlightenment. 
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This is just the beginning. You'll find a collec- 
tion of tools and experiments that go much further 
than this.!? The attacks there use Flush--Reload to 
find out which PDF file you've opened, which web 
pages you're visiting, and more. 


I leave two open challenges to you fine readers: 

1. Make the message-sending tool reliable, so 
that it doesn't mangle messages even a little bit. 
Even cooler would be to make it a two-way reliable 
chat. 

2. Extend the PDF-distinguishing attack in my 
poppler experiment!! to determine which page of 
pocorgtfo14.pdf is being viewed. As I'm reading 
this issue of PoC|IGTFO, I want you to be able to 
tell which page I’m looking at through the side chan- 
nel. 





Best of luck! 
— Taylor Hornby 


lÜgit clone https://github.com/defuse/flush-reload-attacks 


llexperiments/poppler 
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14:05 Anti-Keylogging with Random Noise 


In PoC||GTFO 12:7, we learned that malware is 
inherently “drunk,” and we can exploit its inebria- 
tion. This time, our entonnoir de gavage will be 
filled with random keystrokes instead of single malt. 





Gather ’round, neighbors, as we learn about the 
mechanisms behind the various Windows user-mode 
keylogging techniques employed by malware, and 
then investigate a technique for thwarting them all. 


Background 


Let’s start with a primer on the data flow path of 
keyboard input in Windows. 

Figure 2 is a somewhat simplified diagram of the 
path of a keystroke from the keyboard peripheral de- 
vice (top left), into the Windows operating system 
(left), and then into the active application (right). 
In more detail, the sequence of steps is as follows: 





1. The user presses down on a key. 


2. The keyboard's internal microcontroller con- 
verts key-down activity to a device-specific “s- 
can code," and issues it to keyboard's internal 
USB device controller. 





3. The keyboard's internal USB device controller 
communicates the scan-code as a USB message 
to the USB host controller on the host system. 
The scan code is held in a circular buffer in the 
kernel. 


4. The keyboard driver(s) converts the scan code 
into a virtual key code. The virtual key code 
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is applied as a change to a real-time system- 
wide data struct called the Async Key State 
Array. 


5. Windows OS process Csrcc.exe reads the in- 
put as a virtual key code, wraps it in a Win- 
dows “message,” and delivers it to the message 
queue of the UI thread of the user-mode ap- 
plication that has keyboard focus, along with 
a time-of-message update to a per-thread data 
struct called the Sync Key State Array. 


6. The user application's “message pump” is a 
small loop that runs in its UI thread, retriev- 
ing Windows messages with GetMessage(), 
translating the virtual key codes into usable 
characters with TranslateMessage(), and fi- 
nally sending the input to the appropriate 
callback function for a particular UI element 
(also known as the “Window proc”) that actu- 
ally does something with the input (displays a 
character, moves the caret, etc.). 


For more detail, official documentation of Windows 
messages and Windows keyboard input can be found 
in MSDN MS632586 and MS645530. 


User-Mode Keylogging Techniques in 
Malware 


Malware that wants to intercept keyboard input 
can attempt to do so at any point along this path. 
However, for practical reasons input is usually in- 
tercepted using hooks within an application, rather 
than in the operating system kernel. ‘The reasons 
include: hooking in the kernel requires Adminis- 
trator privilege (including, today, a way to meet 
or circumvent the driver code-signing requirement); 
hooking in the kernel before the keystroke reaches 
the keyboard driver only obtains a keyboard device- 
dependent “scan code” version of the keystroke, 
rather than its actual character or key value; hook- 
ing in the kernel after the keyboard driver but be- 
fore the application obtains only a “virtual key code” 
version of the keystroke (contextual with regard to 
the keyboard “layout” or language of the OS); and 
finally, hooking in the kernel means that the mal- 
ware doesn’t know which application is receiving the 














Keyboard Device 
USB Host Controller Driver 


Callback 


kbdclass.sys 


Returns from ZwReadFile 


Async Key Hardware 
State Array Input Queue 
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Thread 





User-Mode Process 
User32.dll 
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DispatchMessage 
Thread 


Figure 2. Data flow of keyboard input in Windows. 


keyboard input, because the OS has not yet dis- 
patched the keystrokes to the active/focused appli- 
cation. This is why, practically speaking, malware 
only has a handful of locations where it can inter- 
cept keyboard input: upon entering or leaving the 
system message queue, or upon entering or leaving 
the thread message queue. 

Now that we know the hooking will likely be in 
user-mode, we can learn about the methods to do 
user-mode keystroke logging, which include: 


e Hooking the Windows message functions 
TranslateMessage(), GetMessage(), and 
PeekMessage() to capture a copy of messages 
as they are retrieved from the per-thread mes- 





sage queue. 

e Creating a — Windows message hook 
for the  WH KEYBOARD message using 
SetWindowsHookEx(). 

e Similarly, creating a — Windows mes- 
sage hook for the so-called “LowLevel 
Hook" (WH_KEYBOARD_LL) message with 
SetWindowsHookEx(). 


e Similarly, creating a Windows message hook 
for WH_JOURNALRECORD, in order to create a 
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Journal Record Hook. Note: this method has 
been disabled since Windows Vista. 


Polling the system with GetAsyncKeyState(). 


Similarly, polling the system with GetKey- 
boardState() or GetKeyState(). 


Similarly, polling the system with GetRawIn- 
putData(). 


Using DirectX to capture keyboard input 
(somewhat lower-level method). 





Stealing clipboard contents using, e.g., Get- 
ClipboardData(). 


Stealing screenshots or enabling a remote 
desktop view (multiple methods). 


The M. & H. water- mark in a writing paper is a guarantee of excellence. Er 
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The following table lists some pieces of malware 
and which method they use. 


MALWARE | KEYLOGGING TECHNIQUE 


Zeus Hooks TranslateMessage(), 
GetMessage(), PeekMessage(), 
and GetClipboardData(); uses 
GetKeyboardState().!? 
GetMessage(), GetKeyState(), 
PeekMessage C), 
TranslateMessage(), 
GetClipboardData(). 
Hooks TranslateMessage(), 
then uses GetKeyboardState(). 
Polls GetKeyboardLayout (), 
GetAsyncKeyState(), 
GetClipboardData(), and uses 
SetWindowsHookEx(). 
GhOst RAT || Uses SetWindowsHookEx() with 
WH GETMESSAGE, which is another 
way to hook GetMessage(). 


Sality 


SpyEye 


Poison Ivy 


Anti-Keylogging with Keystroke Noise 


One approach to thwarting keyloggers that might 
seem to have potential is: Insert so many phantom 
keyboard devices into the system that the malware 
cannot reliably select the actual keyboard device for 
keylogging. However, based upon our new under- 
standing of how common malware implements key- 
logging, it is clear that this approach will not be 
successful, because malware does not capture key- 
board input by reading it directly from the device. 
Malware is designed to intercept the input at a layer 
high enough as to be input device agnostic. We need 
a different technique. 

Our idea is to generate random keyboard activity 
“noise” emanating at a low layer and removed again 
in a high layer, so that it ends up polluting a mal- 
ware’s keylogger log, but does not actually interfere 
at the level of the user’s experience. Our approach, 
shown in Figure 3, is illustrated as a modification to 
the previous diagram. 





Technical Approach 


What we have done is create a piece of dynamically 
loadable code (currently a DLL) which, once loaded, 
checks for the presence of User32.d11 and hooks its 





imported DispatchMessage() API. From the Dis- 
patchMessage hook, our code is able to filter out 
keystrokes immediately before they would otherwise 
be dispatched to a Window Proc. In other words, 
keystroke noise can be filtered here, at a point after 
potential malware would have already logged it. The 
next step is to inject the keystroke noise: our code 
runs in a separate thread and uses the SendInput () 
API to send random keystroke input that it gener- 
ates. These keystrokes are sent into the keyboard 
IO path at a point before the hooks typically used 
by keylogging malware. 

In order avoid sending keystroke noise that 
will be delivered to a different application and 
therefore not filtered, our code must also use the 
SetWindowsHookEx() API to hook the Window- 
Proc, in order to catch the messages that indi- 
cate our application is the one with keyboard focus. 
WM_SETFOCUS and WM_KILLFOCUS messages indicate 
gaining or losing keyboard input focus. We can’t 
catch these messages in our DispatchMessage() 
hook because, unlike keyboard, mouse, paint, and 
timer messages, the focus messages are not posted to 
the message queue. Instead they are sent directly to 
WindowProc. By coordinating the focus gained/lost 
events with the sending of keystroke noise, we pre- 
vent the noise from "leaking" out to other applica- 
tions. 














Related Research 


In researching our concept, we found some prior art 
in the form of à European academic paper titled 
NoisyKey.!? They did not release their implemen- 
tation, though, and were much more focused on a 
statistical analysis of the randomness of keys in the 
generated noise than in the noise channel technique 
itself. In fact, we encountered several technical ob- 
stacles never mentioned in their paper. We also dis- 
covered a commercial product called IKeystrokeln- 
terference. ‘The trial version of KeystrokeInterfer- 
ence definitely defeated the keylogging methods we 
tested it against, but it did not appear to actually 
create dummy keystrokes. It seemed to simply cause 
keyloggers to gather incomplete data—depending on 
the method, they would either get nothing at all, 
only the Enter key, only punctuation, or they would 
get all of the keystroke events but only the letter “A” 
for all of them. Thus, KeystrokeInterference doesn't 




















127eus’s keylogging takes place only in the browser process, and only when Zeus detects a URL of interest. It is highly 


contextual and configured by the attacker. 


13 NoisyKey: Tolerating Keyloggers via Keystrokes Hiding by Ortolani and Crispo, Usenix Hotsec 2012 
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Figure 3. A noise generating anti-keylogger plugged into the Windows keyboard data flow. 


obfuscate the typing dynamics, and it appears to 
have a fundamentally different approach than we 
took. (It is not documented anywhere what that 
method actually is.) 


Challenges 





For keystroke noise to be effective as interference 
against a keylogger, the generated noise should be 
indistinguishable from user input. Three considera- 
tions to make are the rate of the noise input, emulat- 
ing the real user’s typing dynamics, and generating 
the right mix of keystrokes in the noise. 





Rate is fairly simple: the keystroke noise just has 
to be generated at a high enough rate that it well 
outnumbers the rate of keys actually typed by the 
user. Assuming an expert typist who might type at 
80 WPM, a rough estimate is that our noise should 
be generated at a rate of at least several times that. 
We estimated that about 400 keystrokes per minute, 
or about six per second, should create a high enough 
noise to signal ratio that it is effectively impossible 
to discern which keys were typed. ‘The goal here 
is to make sure that random noise keys separate all 
typed characters sufficiently that no strings of typed 
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characters would appear together in a log. 


Addressing the issue of keystroke dynamics is 
more complicated. Keystroke dynamics is a term 
that refers to the ability to identify a user or what 
they are typing based only on the rhythms of key- 
board activity, without actually capturing the con- 
tent of what they are typing. By flooding the in- 
put with random noise, we should break keystroke 
rhythm analysis of this kind, but only if the in- 
jected keystrokes have a random rhythm about them 
as well. If the injected keystrokes have their own 
rhythm that can be distinguished, then an attacker 
could theoretically learn to filter the noise out that 
way. We address this issue by inserting a random 
short delay before every injected keystroke. The 
random delay interval has an upper bound but no 
lower bound. The delay magnitude here is related 
to the rate of input described previously, but the 
randomness within a small range should mean that 
it is difficult or impossible to distinguish real from 
injected keystrokes based on intra-keystroke timing 
analysis. 





Another challenge was detecting when our appli- 
cation had (keyboard) input focus. It is non-trivial 
for a Windows application to determine when its 


window area has been given input focus: although 
there are polling-based Windows APIs that can pos- 
sibly indicate which Window is in the foreground 
(GetActiveWindow, GetForegroundWindow), they 
are not efficient nor sufficient for our purposes. 
The best solution we have at the moment is that 
we installed a “Window Proc” hook to monitor for 
WM_SETFOCUS and other such messages. We also 
found it best to temporarily disable the keystroke 
noise generation while the user was click-dragging 
the window, because real keyboard input is not 
simultaneously possible with dragging movements. 
There are likely many other activation and focus 
states that we have not yet considered, and which 
will only be discovered through extensive testing. 





Lastly, we had to address the need to gener- 
ate keystroke noise that included all or most of 
the keys that a user would actually strike, includ- 
ing punctuation, some symbols, and capital letters. 
This is where we encountered the difficulty with the 
Shift key modifier. In order to create most non- 
alphanumeric keystrokes (and to create any capital 
letters, obviously), the Shift key needs to be held in 
concert with another key. This means that in order 
to generate such a character, we need to generate a 
Shift key down event, then the other required key 
down and up events, then a Shift key up event. The 
problem lies in the fact that the system reacts to our 
injected shift even if we filter it out: it will change 
the capitalization of the user's actual keystrokes. 
Conversely, the user's use of the Shift key will change 
the capitalization of the injected keys, and our filter 
routine will to fail recognize them as the ones we 
recently injected, allowing them through instead. 





The first solution we attempted was to track ev- 
ery time the user hit the Shift key and every time 
we injected a Shift keystroke, and deconflict their 
states when doing our filter evaluation. Unfortu- 
nately, this approach was prone to failure. Subtle 
race conditions between Async Key State (“true” or 
"system" key state, which is the basis of the Shift 
key state's affect on character capitalization) and 
Sync Key State (“per-thread” key state, which is ef- 
fectively what we tracked in our filter) were difficult 
to debug. We also discovered that it is not possi- 
ble to directly set and clear the Shift state of the 
Async Key State table using an API like SetKey- 
boardStateTable(). 
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We considered using BlockInput () to ignore the 
user’s keyboard input while we generated our own, 
in order to resolve a Shift state confusion. How- 
ever, in practice, this API can only be called from a 
High Integrity Level process (as of Windows Vista), 
making it impractical. It would probably also cause 
noticeable problems with keyboard responsiveness. 
It would not be acceptable as a solution. 

Ultimately, the solution we found was to rely 
on a documented feature of SendInput() that will 
guarantee non-interleaving of inputs. Instead of call- 
ing SendInput() four times (Shift down, key down, 
key up, Shift up) with random delays in between, we 
would instead create an array of all four key events 
and call SendInput once. SendInput () then ensures 
that there are no other user inputs that intermingle 
with your injected inputs, when performed this way. 
Additionally, we use GetAsyncKeyState() immedi- 
ately before SendInput in order to track the actual 
Shift state; if Shift were being held down by the 
user, we would not also inject an interfering Shift 
key down/up sequence. Together, these precautions 





solved the issue with conflicting Shift states. How- 
ever, this has the downside of taking away our ability 
to model a user’s key-down-to-up rhythms using the 
random delays between those events as we originally 
intended. 


Once we had made the change to our use of 
SendInput (), we noticed that these injected noise 
keys were no longer being picked up by certain meth- 
ods of keylogging! Either they would completely not 
see the keystroke noise when injected this way, or 
they saw some of the noise, but not enough for it 
to be effective anymore. What we determined was 
happening is that certain keylogging methods are 
based on polling for keyboard state changes, and 
if activity (both a key down and its corresponding 
key up) happens in between two subsequent polls, it 
will be missed by the keylogger. When using Send- 
Input to instantaneously send a shifted key, all four 
key events (Shift key down, key down, key up, Shift 
key up) pass through the keyboard IO path in less 
time than a keylogger using a polling method can 
detect (at practical polling rates) even though it is 
fast enough to pick up input typed by a human. 
Clearly this will not work for our approach. Unfor- 
tunately, there is no support for managing the rate 
or delay used by SendInput; if you want a key to 
be “held” for a given amount of time, you have to 
call SendInput twice with a wait in between. This 
returns us to the problem of user input being inter- 
leaved with our use of the Shift key. 
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Figure 4. CPU and RAM usage of the PoC 
keystroke noise generator. 


Our compromise solution was to put back our 
multiple SendInput () calls separated by delays, but 
only for keys that didn’t need Shift. For keys that 
need Shift to be held, we use the single SendInput () 
call method that doesn’t interleave the input with 
user input, but which also usually misses being 
picked up by polling-based keyloggers. To account 
for the fact that polling-based keyloggers would re- 
ceive mostly only the slower unshifted key noise that 
we generate, we increased the noise amount propor- 
tionately. This hybrid approach also enables us to 
somewhat model keystroke dynamics, at least for 
the unshifted keystrokes whose timing we can con- 
trol. 








PoC Results 


Our keystroke noise implementation produces suc- 
cessful results as tested against multiple user-mode 
keylogging methods. 

Input-stealing methods that do not involve key- 
logging (such as screenshots and remote desktop) are 
not addressed by our approach. Fortunately, these 
are far less attractive methods to attackers: they 
are high-bandwidth and less effective in capturing 
all input. We also did not address kernel-mode key- 
logging techniques with our approach, but these too 
are uncommon in practical malware, as explained 
earlier. 

Because the keystroke noise technique is an ac- 
tive technique (as opposed to a passive configuration 
change), it was important to test the CPU overhead 
incurred. As seen in Figure 4, the CPU overhead is 
incredibly minimal: it is less than 0.3% of one core of 
our test VM running on an early 2011 laptop with 
a second generation 2GHz Intel Core i7. Some of 
that CPU usage is due to the GUI of the demo app 
itself. The RAM overhead is similarly minimal; but 
again, what is pictured is mostly due to the demo 





























Conclusions 


Although real-time keyboard input is effectively 
masked from keyloggers by our approach, we did not 
address clipboard-stealing malware. If a user were to 
copy and paste sensitive information or credentials, 
our current approach would not disrupt malware's 
ability to capture that information. Similarly, an 
attacker could take a brute-force approach of cap- 
turing what the user sees, and grab keyboard input 
that way (screenshotting or even a live remote desk- 
top session). For approaches like these, there are 
other techniques that one could use. Perhaps they 
would be similar to the keystroke noise concept ( e. g., 
introduce noise into the display output channel, fil- 
ter it out at a point after malware tries to grab it), 
but that is research that remains to be done. 

Console-mode applications don't rely on Win- 
dows messages, and as such, our method is not yet 
compatible with them. Console mode applications 
retrieve keyboard input differently, for example us- 
ing the kbhit() and getkey() APIs. Likewise, any 
Windows application that checks for keyboard input 
without any use of Windows Messages (rare, but 
theoretically possible), for example by just polling 
GetKeyboardState(), is also not yet compatible 
with our approach. There is nothing fundamentally 
incompatible; we would just need to instrument a 
different set of locations in the input path in order 
to filter out injected keyboard input before it is ob- 
served by console-mode applications or “abnormal” 
keyboard state checking of this sort. 

Another area for further development is in the 
behavior of SendInput (). If we reverse engineer the 
SendInput API, we may be able to reimplement it 
in a way specifically suited for our task. Specifically 
we would like the timing between batched input 
elements to be controllable, while maintaining the 
input interleaving protection that it provides when 
called using batched input. 

We discovered during research that a “low- 
level keyboard hook" (SetWindowsHookEx() with 
WH KEYBOARD LL) can check a flag on each call- 
back called LLKHF. INJECTED, and know if the 
keystroke was injected in software, e.g., by a call 
to SendInput(). So in the future we would 
also seek a way to prevent win32k.sys from set- 
ting the LLKHF INJECTED flag on our injected 
keystrokes. This flag is set in the kernel by 
win32k.sys!XxxKeyEvent, implying that it may re- 
quire kernel-level code to alter this behavior. Al- 
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though this would seem to be a clear way to de- 
feat our approach, it may not be so. Although we 
have not tested it, any on-screen keyboard or re- 
motely logged-on user's key inputs supposedly come 
through the system with this flag set, so a keylogger 
may not want to filter on this flag. Once we pro- 
pose loading kernel code to change a flag, though, 
we may as well change our method of injecting input 
and just avoid this problem entirely. By so doing we 
could also likely address the problem of kernel-mode 
keyloggers. 
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14:06 How likely are random bytes to be a NOP sled on ARM? 


Howdy folks! 

Any of you ever wondered what the probability 
is for executing random bytes in order to do some- 
thing useful? We certainly do. The team respon- 
sible for analyzing the Nintendo 3DS might have 
wondered about an answer when they identified the 
lst stage boot loader of the security processor is 
only encrypted and not authenticated.!^ This al- 
lowed them to execute random bytes in the security 
processor by changing the original unauthenticated, 
but encrypted, image. Using a trial and error ap- 
proach, they were able to get lucky when the image 
decrypts into code that jumps to a memory location 
preloaded with arbitrary code. Game over for the 
Nintendo 3DS security processor. 

We generalize the potential attack primitive of 
executing random bytes by focusing on one ques- 
tion: What is the probability of executing random 
bytes in a NOP-like fashion? NOP-like instructions 
are those that do not impair the program's contin- 
uation, such as by crashing or looping. 

Writing NOPs into a code region is a powerful 
method which potentially allows full control over the 
system's execution. For example, the NOPs can be 
used to remove a length check, leading to an ex- 
ploitable buffer overflow. One can imagine various 
practical scenarios to leverage this attack primitive, 
both during boot and runtime of the system. 

A practical scenario during boot is related to 
a common feature implemented by secure embed- 
ded devices: Secure Boot. This feature provides in- 
tegrity and confidentiality of code stored in external 
flash. Such implementations are compromised using 
software attacks!? and hardware attacks.!ó Depend- 
ing on the implementation, it may be possible to 
bypass the authentication but not the decryption. 
In such a situation, similar to the Nintendo 3D$, 
changing the original encrypted image will lead to 
the execution of randomized bytes as the decryption 
key is likely unknown. 

During runtime, secure embedded devices often 
provide hardware cryptographic accelerators that 
implement Direct Memory Access (DMA). This 
functionality allows on-the-fly decryption of memory 
from location A to location B. It is of utmost im- 
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portance to implement proper restrictions to prevent 
unprivileged entities from overwriting security sensi- 
tive memory locations, such as code regions. When 
such restrictions are implemented incorrectly, it po- 
tentially leads to copying random bytes into code 
regions. 

The block size of the cipher impacts the size di- 
rectly: 8 bytes for T/DES and 16 bytes for AES. Ad- 
ditionally the cipher mode has an impact. When the 
image is decrypted using ECB, an entire block will 
be pseudo randomized without propagating to other 
blocks. When the image is decrypted using CBC, an 
entire block will be pseudo randomized. Addition- 
ally, any changes in a cipher block will propagate 
directly into the plain text of the subsequent block. 
In other words, flipping a bit in the cipher text will 
flip the bit at the same position in the plain text of 
the subsequent block. This allows small modifica- 
tions of the original plain text code which potential 
leads to arbitrary code execution. Further details 
for such attacks are for another time. 





The pseudo random bytes executed in these sce- 
narios must be executed in a NOP-like fashion. This 
means they need too be decoded into: valid in- 
structions and have no side-effect on the program’s 
continuation. The amount of different instruction 
matching these requirements are target dependent. 
Whenever these requirements are not met, the de- 
vice will likely crash. 








We approximated the probability for executing 
random bytes in a NOP-like fashion for Thumb and 
ARM and under different conditions: QEMU, native 
user and native bare-metal. For each execution, the 
probability is approximated for executing 4, 8 and 
16 random bytes. Other architectures or execution 
states are not considered here. 
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Executing in QEMU 


The probability of executing random bytes in a 
NOP-like fashion is determined using two pieces of 
software: a Python wrapper and an Thumb/ARM 
binary containing NOPs to be overwritten. 


void main (void) { 


printf ("FREE ") ; 
asm volatile ( 
" E [s Place holder bytes 


els n 
pr" n m 


ris n 


printf ("BEER!") ; 


This is cross compiled for Thumb and ARM, 
then executed in QEMU. 


arm-linux—gnueabihf—gcc —o test—arm \ 





test —arm.c —static —marm (—mthumb) 
qemu—arm test-arm 





Whenever the test program prints “FREE 
BEER" the instructions executed between the two 
printf calls do not impact the program's execution 
negatively; that is, the instructions are NOP-like. 
The Python wrapper updates the place holder bytes 
with random bytes, executes the binary, and logs the 
printed result. 

The random bytes originate from /dev/urandom. 
Executing the updated binary results in: intended 
(NOP-like) executions, unintended executions (e.g. 
only “FREE” is printed) and crashes. The results of 
executing the binary ten thousand times, grouped 
by type, are shown in Table 1. A small percentage 
of the results are unclassified. 

The results show that executing random bytes 
in a NOP-like fashion has potential for emulated 
Thumb/ARM code. The amount of random bytes 
impact the probability directly. The density of bad 
instructions, where the program crashes, is higher 
for Thumb than for ARM. Let’s see if the same prob- 
ability holds up for executing native code. 
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Cortex A9 as a Native User 


The binary used to approximate the probability on 
a native platform in user mode is similar as listed in 
Section 2. Differently, this code is executed natively 
on an ARM Cortex-A9 development board. ‘The 
code is developed, compiled and executing within 
the Ubuntu 14.04 LT'S operating system. A disas- 
sembled representation of the ARM binary is shown 
below: 








10804: 
10808: 
1080c: 


e92d4800 push {fp, lIr} 
e28db004 add fp, sp, #4 
ebfffff0 bl 107d4 «pl» 


// These bytes are updated by the 
// python wrapper before each execution. 
10810: 


ela01001 mov ri, ri 
ela01001 mov ri, ri 
ela01001 mov ri, ri 
ela01001 mov ri, Xd 
ebfffffl bl 107ec <p2> 
e8bd8800 pop {fp, pc} 


10814: 
10818: 
1081c: 
10820: 
10824: 


The results of performing one thousand experi- 
ments are listed in Table 2 


The results show that executing random bytes 
in a NOP-like fashion is very similar between em- 
ulated code and native user mode code. Let's see 
if the same probability holds up for executing bare- 
metal code. 
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Cortex A9 as Native Bare Metal 


The binary used to approximate the probability on 
native platform in bare metal mode is implemented 
in U-Boot. The code is very similar to that which 
we used on Qemu and in userland. U-Boot is only 
executed during boot and therefore the platform is 
executed before each experiment. The target’s serial 
interface is used for communication. A new com- 
mand is added to U-Boot which is able to receive 
random bytes via the serial interface, update the 
placeholder bytes and execute the code. 

All ARM CPU exceptions are handled by U- 
Boot which allows us to classify the crashes ac- 
cordingly. For example, the following exception is 
printed on the serial interface when the random 
bytes result in a illegal exception: 
FREE undefined instruction 
pe [<1ff50218 >] Ir 
reloc pc [040 EOS | lr 
sp : leb19e68 ip : 0000000c fp 
rl0Q0: 00000000 r9 leb19ee8 
r8 : 1c091c09 r7 1ff503fc r6 
rd : 00000000 r4 1ff50214 r3 
r2 : 0000080a ri 1ff50214 roO 


Flags: nZCv  IRQs oft FIQs off 
Resetting CPU 











[«1ff5020c >] 
[<0401620c>] 
00000000 


1ff503fc 


e0001000 
: 00000005 
Mode SVC 32 


The results of performing one thousand experi- 
ments are listed in Table 3. 

The results show that executing random bytes 
in a NOP-like fashion is similar for bare-metal code 
compared to emulated and native user mode code. 
There seems to be less difference between Thumb 
and ARM but that could be due statistics. 





Conclusion 


Let us wonder no more. The results of this arti- 
cle tell us that the probability for executing random 
bytes in a NOP-like fashion for Thumb an ARM is 
significant enough to consider it a potentially rele- 
vant attack primitive. The probability is very simi- 
lar for execution of emulated code, native user-mode 
code and bare-metal code. The number of ran- 
dom bytes executed impact the probability directly 
which matches our common sense. In Thumb mode, 
the density of bad instructions where the program 
crashes is higher than for ARM. One must realize 
the true probability for a given target cannot be 
determined in a generic fashion, thanks to memory 
mapping, access restrictions, and the surrounding 
code. 
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Type 4 bytes 8 bytes 16 bytes 
NOP-like 32% / 52% 138% / 34% 4% / 13% 
Illegal instruction 11% / 20% 14% / 29% 15% / 41% 
Segmentation fault 52% / 23% 66% / 31% 73% / 40% 
Unhandled CPU exception 1% / 2% 0% / 3% 0% / 4% 
Unhandled ARM syscall 1% / 0% 1% / 1% 1% / 1% 
Unhandled Syscall 1% / 1% 0% / 0% 0% / 096 
Unclassified 5% / 3% 6% / 2% 6% / 1% 


Table 1. Probabilities for QEMU (Thumb / ARM) 


Type 
NOP-like 


Illegal instruction 
Segmentation fault 


Bus error 


Unclassified 


4 bytes 
36% | 61% 
13% / 19% 
4896 / 19% 
0% / 1% 
3% / 0% 


8 bytes 
13% / 39% 
11961-2476 
66% / 337% 
0% / 1% 
496 / O% 


16 bytes 
2% | 12% 
23% / 40% 
71% / 46% 
0% / 2% 
496 / O% 


Table 2. Probabilities for native user (Thumb / ARM) 


Type 
NOP-like 


Undefined Instruction 


Data Abort 


Prefetch Abort 
Unclassified 


4 bytes 


53% | 63% 
16% / 20% 


17% / 4% 
196 / 196 


15% / 12% 


8 bytes 


32% | 41% 
19% / 34% 


25% / 7% 
1% / 1% 


23% / 18% 


16 bytes 
7% / 19% 
25% / 51% 
33% / 11% 
2% / 1% 
33% / 18% 


Table 3. Probabilities for native bare metal (Thumb / ARM) 
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14:07 


Hello again friendly and distinguished neighbors! 
As you can see, I’ve already started compliment- 
ing you, in part to distract from the tiny horrors 
ahead. Lately I've been spending some time ex- 
perimenting on chips, injecting faults, and gener- 
ally trying to guess how they are programmed. The 
results are a delightful topic that we have visited 
some in the past, and I'll surely weave some new sto- 
ries about my results in the brighter days to come. 
For now, deep in the thick of things, you see, the 
glitching is monotonous work. Today's article is a 
tidbit about one particular solution to a problem I 
found while experimenting with voltage glitching a 
network-connected microcontroller. 


Problem with Time Bubbles 


Slow experiments repeat for days, and the experi- 
ments are often made slower on purpose by under- 
clocking, broadening the little glitch targets we hope 
to peck at in order for the chip to release new secrets. 
To whatever extent I can, I like to control the clock 
frequency of a device under investigation. It helps 
to vary at least one clock to understand which parts 
of the system are driven by which clock sources. A 
slower clock can reduce the complexity of the tools 
you need for power analysis, accurate fault injection, 
and bus tracing. 

If we had a system with a fully static design 
and a single clock, there wouldn't be any limit 
to the underclocking, and the system would follow 
the same execution path even if individual clock 
edges were delivered bi-weekly by pigeon. In real- 
ity, systems usually have additional clock domains 
driven by free-running oscillators or phase-locked 
loops (PLLs). This system design can impose lim- 
its on the practical amount of underclock you can 
achieve before the PLL fails to lock, or a watchdog 
timer expires before the software can make sufficient 
progress. On the bright side, these individual limita- 
tions can themselves reveal interesting information 
about the system's construction, and it may even 
be possible to introduce timing-related glitches in- 
tentionally by varying the clock speed. 

These experiments create a bubble of alternate 
time, warped to your experiment's advantage. Any 
protocol that traverses the boundary between un- 
derclocked and real-time domains may need to be 


























30 


Routing Ethernet over GDB and SWD for Glitching 


by Micah Elizabeth Scott 


modified to account for the time difference. An SPI 
peripheral easily accepts a range of SCLK frequen- 
cies, but a serial port expecting 115,200 baud will 
have to know it’s getting 25,920 baud instead. Most 
serial peripherals can handle this perfectly accept- 
ably, but you may notice that operating systems and 
programming APIs start to turn their nose up at 
such a strange bit rate. ‘Things become even less 
convenient with fixed-rate protocols like USB and 
Ethernet. 

As fun as it would be to implement a custom 
Ethernet PHY that supports arbitrary clock scal- 
ing, it’s usually more practical to extend the time 
bubble, slowing the input clock presented to an oth- 
erwise mundane Ethernet controller. For this tech- 
nique to work, the peripheral needs a flexible inter- 
facing clock. A USB-to-Ethernet bridge like the one 
on-board a Raspberry Pi could be underclocked, but 
then it couldn’t speak with the USB host controller. 
PCI Express would have a similar problem. 

SPI peripherals are handy for this purpose. My 
earlier Facewhisperer mashup of Facedancer and 
ChipWhisperer spoke underclocked USB by includ- 
ing a MAX3421E chip in the victim device’s time 
domain. This can successfully break free from the 
time bubble, thanks to this chip talking over an SPI 
interface that can run at a flexible rate relative to 
the USB clock. 

At first I tried to apply this same technique to 
Ethernet, using the ENC28J60, a 10baseT Ethernet 
controller that speaks SPI. This is even particularly 
easy to set up in tandem with a (non-underclocked) 
Raspberry Pi, thanks to some handy device tree 
overlays. This worked to a point, but the ENC28J60 
proved to be less underclockable than my target mi- 
crocontroller. 

There aren't many SPI Ethernet controllers to 
choose from. I only know of the ’28J60 from Mi- 
crochip and its newer siblings with 100baseT sup- 
port. In this case, it was inconvenient that I was 
dealing with two very different internal PHY designs 
on each side of the now very out-of-spec Ethernet 
link. I started making electrical changes, such as re- 
moving the AC coupling transformers, which needed 
somewhat different kludges for each type of PHY. 
This was getting frustrating, and seemed to be lim- 
iting the consistency of detecting a link successfully 
at such weird clock rates. 















GET A WRIST 
TERMINAL 
OR YOUR 
COMPUTER 





The 
Seiko Datagraph 


UNDER $200 


Available for: 
Apple II, II + , Ic, He 


IBM-PC and compatibles 
Commodore TRS-80 | 


FOR COMPLETE PRODUCT LIST AND INFORMATION 
SEND ONE DOLLAR TO: 


HI-TECH RECORD SYSTEMS” 


13424 Whittier Blvd 
Whittier, CA 90605 


or call 
In L.A. (213) 945-2668 
Outside L.A. (800) 448-5709 


ORDER NOW FOR CHRISTMAS DELIVERY 


3l 


At this point, it seemed like it would be awfully 
convenient if I could just use the exact same kind of 
PHY on both sides of the link. I could have rewrit- 
ten my glitch experiment request generator program 
as a firmware for the same type of microcontroller, 
but I preferred to keep the test code written in 
Python on a roomy computer so I could prototype 
changes quickly. These constraints pointed toward a 
fun approach that I had not seen anyone try before. 


Ethernet over GDB 


When I'm designing anything, but especially when 
I’m prototyping, I get a bit alarmed any time the de- 
sign appears to have too many degrees of freedom. 
It usually means I could trade some of those extra 
freedoms for the constraints offered by an existing 
component somehow, and save from reinventing all 
the boring wheels. 

The boring wheel I’d imagined here would have 
been a firmware image that perhaps implements a 
simple proxy that shuttles network frames and per- 
haps link status information between the on-chip 
Ethernet and an arbitrary SPI slave implementa- 
tion. The biggest downside to this is that the SPI 
interface would have to speak another custom pro- 
tocol, with yet another chunk of code necessary 
to bridge that SPI interface to something usable 
like a Linux network tap. It’s tempting to imple- 
ment standard USB networking, but an integrated 
USB controller would ultimately use the same clock 
source as the Ethernet PHY. It’s tempting to emu- 
late the ENC28J60’s SPI protocol to use its exist- 
ing Linux driver, but emulating this protocol’s quick 
turnaround between address and data without get- 
ting an FPGA involved seemed unlikely. 

In this case, the microcontroller hardware was 
already well-equipped to shuttle data between its 
on-chip Ethernet MAC and a list of packet buffers 
in main RAM. I eventually want a network device 
in Linux that I can really hang out with, captur- 
ing packets and setting up bridges and all. So, in 
the interest of eliminating as much glue as possi- 
ble, I should be talking to the MAC from some code 
that’s also capable of creating a Linux network tap. 
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int main(void) { 
MAP SysCtlIMOSCConfigSet (SYSCIL MOSC HIGHFREQ) ; 
g ui32SysClock = MAP $SysCtlClockFreqSet ((SYSCTL XTAL 25MHZ | 
SYSCIL OSC MAIN | 
SYSCTL USE PLL | 
SYSCTL CFG VCO 480), 120000000); 


PinoutSet(true, false); 





MAP SysCtlPeripheralEnable(SYSCTL PERIPH EMACO) ; 

MAP SysCtlPeripheralReset (SYSCTL PERIPH EMACO) ; 

MAP SysCtlPeripheralEnable(SYSCTL PERIPH EPHYO); 

MAP SysCtlPeripheralReset (SYSCTL PERIPH EPHYO); 

while (!MAP SysCtlPeripheralReady (SYSCTL PERIPH EMACO) ) ; 





MAP EMACPHYConfigSet (EMACO BASE, 

EMAC PHY TYPE INTERNAL | 

EMAC PHY INT MDI SWAP | 

EMAC PHY INT FAST L UP DETECT | 
EMAC PHY INT EXT FULL DUPLEX | 
EMAC PHY FORCE 10B T FULL DUPLEX) ; 





MAP EMACReset(EMACO BASE); 


MAP EMACInit(EMACO BASE, g ui32SysClock, 
EMAC BCONFIG MIXED BURST | EMAC BCONFIG PRIORITY FIXED, 
Sa. 38% :0)3 


MAP _EMACConfigSet (EMACO_ BASE, 
(EMAC CONFIG FULL ADUE LES " 





EMAC CONFIG IF GAP 96BITS i 

EMAC CONFIG USE MACADDRO | 

EMAC CONFIG SA FROM DESCRIPTOR. | 
EMAC CONFIG BO LIMIT 1024), 

(EMAC MODE RX SIORE FORWARD | 
EMAC MODE TX STORE FORWARD ), 0); 





MAP EMACFrameFilterSet (EMACO BASE, EMAC FRMFILTER RX ALL); 


init dma frames(); 


MAP EMACTXxEnable(EMACO BASE); 
MAP ~ EMACRxEnable (EMACO BASE); 


while (1) ( 
capture phy regs(); 
|» volatile ("bkpt"); 





Figure 5. TMAC129x Firmware 
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This is where GDB, OpenOCD, and the Rasp- 
berry Pi really save the day. I thought I was go- 
ing to be bit-banging the Serial Wire Debug (SWD) 
protocol again on some microcontroller, then build- 
ing up from there all of the device-specific goodies 
necessary to access the memory and peripheral bus, 
set up the system clocks, and finally do some ac- 
tual internetworking. It involves a lot of tedious 
reimplementation of things the semiconductor ven- 
dor already has working in a different language or 
a different format. But with GDB, we can make a 
minimal Ethernet setup firmware with whatever li- 
braries we like, let it initialize the hardware, then 
inspect the symbols we need at runtime to handle 
packets. 








At this point I can already hear some of you 
groaning about how slow this must be. While this 
debug bus won't be smoking the tires on a 100baseT 
switch any time soon, it's certainly usable for experi- 
mentation. In the specific setup I'll be talking about 
in more detail below, the bit-bang SWD bus runs at 
about 10 megabits per second peak, which turns into 
an actual sustained Ethernet throughput of around 
130 kilobytes per second. It's faster than many in- 
ternet connections I've had, and for microcontroller 
work it's been more than enough. 





There's a trick to how this crazy network driver 
is able to run at such blazingly adequate speeds. 
Odds are if you're used to slow on-chip debugging, 
most of the delays have been due to slow round trips 
in your communication with the debug adapter. 
How bad this is depends on how low-level your de- 
bug adapter protocol happens to be. Does it make 
you schedule a USB transfer for every debug trans- 
action? There goes a millisecond. Some adapters 
are much worse, some are a little better. ‘Thanks 
to the Raspberry Pi 2 and 3 with their fast CPU 
and memory-mapped GPIOs, an OpenOCD process 
in userspace can bitbang SWD at rates competi- 
tive with a standalone debug adapter. By elimi- 
nating the chunky USB latencies we can hold con- 
versations between hardware and Python code im- 
pressively fast. Idle times between SWD transfers 
are 10-50 microseconds when we’re staying within 
OpenOCD, and as low as 150us when we journey 
all the way back to Python code. 








After building up a working network interface, 
it’s easy to go a little further to add debugging hooks 
specific to your situation. In my voltage glitching 
setup, I wanted some hardware to know in advance 
when it was about to get a specific packet. I could 
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add some string matching code to the Python proxy, 
using the Pi's GPIOs to signal the results of catego- 
rizing packets of interest. This signal itself won’t be 
synchronized with the Ethernet traffic, but it was 
perfect for use as context when generating synchro- 
nized triggers on a separate FPGA. 


You’re being awfully vague, I thought 
there was a proof of concept here? 


Okay, okay. Yes, I have one, and of course I'll share 
it here. But I did have a point; the whole process 
turned out to be a lot more generic than I expected, 
thanks to the functionality of OpenOCD and GDB. 
The actual code I wrote is very specific to the SoC 
I'm working with, but that’s because it reads like a 
network driver split into a C and a Python portion. 

If you're interested in a flexibly-clocked Ether- 
net adapter for your Raspberry Pi, or you're hack- 
ing at another network-connected device with the 
same micro, perhaps my code will interest you as-is, 
but ultimately I hope my humble PoC might inspire 
you to try a similar technique with other micros and 
peripherals. 
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Tiva GDBthernet 


So the specific chip I've been working with is a 120 
MHz ARM Cortex-M4F core with on-board Ether- 
net, the TM4C129x, otherwise known as the Tiva-C 
series from Texas Instruments. Luckily there's al- 
ready a nice open source project to support building 
firmware for this platform with GCC.!* The plat- 
form includes some networking examples based on 
the uIP and IwIP stacks. For our purposes, we need 
to dig a bit lower. The on-chip Ethernet MAC uses 
DMA both to transfer packet contents and to access 
a queue made from DMA Descriptor structures. 
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TDES2 Buffer1 Address [31:0] 





TDES3 Buffer2 Address [31:0]/Next Descriptor Address [31:0] 





TDES4 Reserved 





TDES5 Reserved 





TDES6 Transmit Timestamp Low [31:0] 





TDES7 Transmit Timestamp High [31:0] 











This data structure is convenient enough to 
access directly from Python when we're shuttling 
packets back and forth, but setting up the periph- 
eral involves a boatload of magic numbers that I'd 
prefer not to fuss with. We can mostly reuse ex- 
isting library code for this. The main firmware file 
gdbthernet.c uses a viscous wad of library calls to 
set up all the hardware we need, before getting itself 
stuck in a breakpoint loop, shown in Figure 5. 

Everything in this file only needs to exist for 
convenience. The micro doesn't need any firmware 
whatsoever, we could set up everything from GDB. 
But it's easier to reuse whatever we can. You may 
have noticed the call to capture. phy. regs () above. 
We have only indirect access to the PHY registers 
via the Ethernet MAC, so it was a bit more conve- 
nient to reuse existing library code for reading those 
registers to determine the link state. 


l7git clone https://github.com/yuvadm/tiva-c 
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On the Raspberry Pi side, we start with a shell 
script proxy.sh that spawns an OpenOCD and 
GDB process, and tells GDB to run gdb net - 
host.py. Some platform-specific configuration for 
OpenOCD tells it how to get to the processor and 
which micro we're dealing with. GDB provides quite 
high-level access to parse expressions in the target 
language, and the Python API wraps those results 
nicely in data structures that mimic the native lan- 
guage types. My current approach has been to use 
this parsing sparingly, though, since it seems to 
leak memory. Early on in gdb net host.py, we 
scrape all the constants we'll be needing from the 
firmware's debug symbols. (Figure 6.) 


From here on, we'll expect to chug through all 
of the Raspberry Pi CPU cycles we can. "There's 
no interrupt signaling back to the debugger, every- 
thing has to be based on polling. We could poll for 
Ethernet interrupts, but it's more expedient to poll 
the DMA Descriptor directly, since that's the data 
we actually want. Here's how we receive Ethernet 
frames and forward them to our tap device. (Fig- 
ure 7.) 





The transmit side is similar, but it's driven by 
the availability of a packet on the tap interface. You 
can see the hooks for GPIO trigger outputs in Fig- 
ure 8. 


That's just about all it takes to implement a 
pretty okay network interface for the Raspberry Pi. 
Attached you'll find the few necessary but boring 
tidbits I’ve left out above, like link state detection 
and debugger setup. I’ve been pretty happy with 
the results. ‘This approach is even comparable in 
speed to the ENC28J60 driver, if you don't mind 
the astronomical CPU load. I hope this trick in- 
spires you to create weird peripheral mashups using 
GDB and the Raspberry Pi. If you do, please be a 
good neighbor and consider documenting your ex- 
perience for others. Happy hacking! 





inf = gdb.selected inferior () 
num rx = int(gdb.parse and eval('sizeof g rxBuffer / sizeof g rxBuffer[0]’)) 
num tx = int(gdb.parse and eval('sizeof g txBuffer / sizeof g txBuffer [0] ')) 


g phy bmcr = int(gdb.parse and eval('(int)&g phy.bmcr')) 
g phy bmsr = int(gdb.parse and eval('(int)&g phy.bmsr')) 
g phy cfgl = int(gdb.parse and eval('^(int)&g phy.cfgl’)) 
g phy sts = int(gdb.parse and eval('(int)&g phy.sts’)) 
rx status = [int(gdb.parse and eval ( 
'(int)&g rxBuffer[%d]|.desc.ui32CtrlStatus’ % i)) for i in range(num_rx) | 
rx frame = [int(gdb.parse and eval ( 
'(int)g rxBuffer[Vod].frame' % 1)) for i in range(num rx)] 
tx status = [int(gdb.parse and eval( 
'(int)&g txBuffer[%d]|.desc.ui32CtrlStatus’ % i)) for i in range(num_tx) | 
tx count = [int(gdb.parse and eval ( 
'(int)&g txBuffer|%d|.desc.ui32Count’ % i)) for i in range(num tx) | 
tx frame = [int(gdb.parse and eval('(int)g txBuffer|[%d|.frame’ 96 i)) for i in range(num_tx) | 





Figure 6. Fetching Debug Symbols 


next rx 


def rx poll demand(): 
# Rx Poll Demand (wake up MAC if it’s suspended) 
inf.write memory(0x400ECCO08, struct.pack( «I^, OxFFFFFFFF)) 


poll rx(tap): 
global next rx 


status = struct.unpack(' «I^, inf.read memory(rx status[next rx], 4)) [0] 
if status & (1 «« 31): 

# Hardware still owns this buffer; try later 

return 


if status & (1 << 11): 
print(’RX Overflow error’) 
elif status & (1 << 12): 
print ("RX Length error’) 
elif status & (1 «« 3): 
print(’RX Receive error’) 
elif status & (1 << 1): 
print ("RX CRC error’) 
elif (status & (1 << 8)) and (status & (1 << 9)): 
A Complete frame (first and last parts), strip 4—byte FCS 
length = ((status >> 16) & Ox3FFF) — 4 
frame = inf.read memory(rx frame[next rx], length) 
if VERBOSE: 
print (’RX %r’ % binascii.b2a hex(frame)) 
tap. write(frame) 
else: 
print(’RX unhandled status %08x’ % status) 


# Return the buffer to hardware, advance to the next one 

inf.write memory(rx status|[next rx], struct.pack(’<I’, 0x80000000) ) 
next rx = (next rx + 1) % num rx 

rx poll demand() 

return True 





Figure 7. Ethernet Frame RX 
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l| next tx = 0 








tx buffer stuck count = 0 
3 
def tx poll demand(): 
5 # Tx Poll Demand (wake up MAC if it’s suspended) 
inf.write memory(0x400ECCO04, struct.pack( «I^, OxFFFFFFFF)) 
7 
def poll tx(tap): 
9 global next tx 
global tx buffer stuck count 
11 
status = struct.unpack(’<I’, inf.read memory(tx status[next tx], 4)) [0] 
13 if status & (1 << 31): 
print(’TX waiting for buffer %d’ 96 next tx) 
15 tx buffer stuck count += 1 
if tx buffer stuck count > 5: 
17 gdb.execute( run") 
update phy status() 
19 tx poll demand() 
return 
21 
tx buffer stuck count = 0 
23 if not select.select([tap.fileno()]l, [], [], ©) [0]: 
return 
25 frame = tap.read (4096) 
27 match low = TRIGGER and frame. find (TRIGGER LOW) >= 0 
match high = TRIGGER and frame. find (TRIGGER HIGH) >= 0 
29 
if VERBOSE: 
31 print (’TX %r’ % binascii.b2a hex(frame)) 
33 if match_ low: 
if VERBOSE: 
35 print(’—’ * 60) 
GPIO. output (TRIGGER PIN, GPIO.LOW) 
37 
inf.write memory(tx frame|[next tx], frame) 
39 inf.write memory(tx count[next tx], struct.pack(’<I’, len(frame) ) ) 
inf.write memory(tx_status|[next tx], struct.pack(’<I’, 
41 0x80000000 | # DESO RX CIRL OWN 
0x20000000 | # DES0 TX CTRL LAST SEG 
43 0x10000000 | # DESO TX CTRL FIRST SEG 
0x00100000)) # DESO TX CTRL CHAINED 
45 next tx = (next tx + 1) % num tx 
4T if match high: 
GPIO. output (TRIGGER PIN, GPIO.HIGH) 
49 if VERBOSE: 
print(’+’ * 60) 
ol 
tx poll demand () 
o3 return True 


Figure 8. Ethernet Frame T'X 
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14:08 Control Panel Vulnerabilities 


Back in 2010, as what I then feared might be 
“the last new work that I will ever publish,” I wrote 
The CPL Icon Loading Vulnerability!® about what 
Microsoft called a Shortcut Icon Loading Vulnerabil- 
ity.? You likely remember this vulnerability. It was 
notorious for having been exploited by the Stuxnet 
worm to spread between computers via removable 
media. Just browsing the files on an infected USB 
drive was enough to get the worm loaded and exe- 
cuting. 





Years later, over drinks at a bar in the East Vil- 
lage, I brought up this case to support a small provo- 
cation that the computer security industry does not 
rate the pursuit of detail as highly as it might— 
or even as highly as it likes to claim. ‘Thus did 
I recently reread my 2010 article, which I always 
was unhappy to have put aside in haste, and looked 
again at what others had written. To my surprise— 
or not, given that I had predicted “the defect may 
not be properly fixed"—I saw that others had re- 
visited the issue too, in 2015 while I wasn't look- 
ing. As reported by Dave Weinstein in Full details 
on CVE-2015-0096 and the failed MS10-046 Stuxnet 
fix"? Michael Heerklotz showed that Microsoft had 
not properly fixed the vulnerability in 2010. Numer- 
ous others jumped on the bandwagon of scoffing at 
Microsoft for having needed a second go. I am writ- 
ing about this vulnerability now because I think we 
might do well to have a third look! 


Don't get too excited, though. It’s not that 
Microsoft's second fix, of a DLL Planting Remote 
Code Execution Vulnerability?! still hasn't com- 
pletely closed off the possibilities for exploitation. 
I'm not saying that Microsoft needs a third attempt. 
I will show, however, that the exploitation that mo- 
tivated the second fix depends on some extraordi- 
narily quirky behaviour that this second fix left in 
place. It is not credibly retained for backwards com- 
patibility. That it persists is arguably a sign that we 
still have a long way to go for how the computer se- 
curity industry examines software for vulnerabilities 
and for how software manufacturers fix them. 


by Geoff Chappell 


CV E-2010-2568 


You'd hope that Stuxnet's trick has long been un- 
derstood in detail by everyone who ever cared, but 
let's have a quick summary anyway. Among the 
browsed files is a shortcut (.LNK) file that presents 
as its target a Control Panel item whose icon is to 
be resolved dynamically. Browsing the shortcut in- 
duces Windows to load and execute the correspond- 
ing CPL module to ask it which icon to show. This 
may be all well and good if the CPL module ac- 
tually is registered, so that its Control Panel items 
would show when browsing the Control Panel. The 
exploitation is simply that the target's CPL module 
is (still) not registered but is (instead) malware. 

Chances are that you remember CV E-2010-2568 
and its exploitation differently. After all, Microsoft 
had it that the vulnerability “exists because Win- 
dows incorrectly parses shortcuts" and is exploited 
by “a specially crafted shortcut." Some malware an- 
alysts went further and talked of a *malformed .LNK 
file." 

But that's all rubbish! A syntactically valid .LNK 
file for the exploitation can be created using nothing 
but the ordinary user interface for creating a short- 
cut to a Control Panel item. Suppose an attacker 
has written malware in the form of a CPL module 
that hosts a Control Panel item whose icon is to be 
resolved dynamically. Then all the attacker has to 
do at the attacker's computer is as follows. 





e First copy this CPL module to the USB drive; 


e register this CPL module so that it will show 
in the Control Panel; 


e open the Control Panel and find the Control 
Panel item; and, 


e Ctrl-Shift drag this item to the USB drive to 
create a .LNK file. 


Call the result a “specially crafted shortcut" if 
you want, but it looks to me like a very ordinary 
shortcut created by very ordinary steps. When the 
USB drive is browsed on the victim's computer, 


1Shttp://www.geoffchappell.com/notes/security/stuxnet/ctrlfldr.htm 


19MS10-046 and CVE-2010-2568 
20HP Enterprise, March 2015 
21MS15-020, CVE-2015-0096 
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attacker’s .LNK file on the USB drive is correctly 
parsed to discover that it’s a shortcut to a Con- 
trol Panel item that’s hosted by the attacker’s CPL 
module on the USB drive. Though this CPL mod- 
ule is not registered for execution as a CPL module 
on the victim's computer, it does get executed. The 
cause of this unwanted execution is entirely that the 
Control Panel is credulous that what is said to be a 
Control Panel item actually 4s one. What the Con- 
trol Panel was vulnerable to was not a parsing error 
but a spoof.?? 
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Microsoft certainly understood this at the time, 
for even though the words Control Panel do not 
appear in Microsoft’s description of the vulnerabil- 
ity (except in boilerplate directions for such things 
as applying patches and workarounds), the essence 
of the first fix was the addition to shel132.d11 
of a routine that symbol files tell us is named 
CControlPanelFolder:: IsRegisteredCPLApplet. 





Control Panel Icons 


This CControlPanelFolder class is the shell's im- 
plementation of the COM class that is creatable 
from the Control Panel's well-known CLSID. Asking 
which icon to show for a Control Panel item starts 
with a call to this class’ GetUIObjectOf method to 
get an IExtractIcon interface to a temporary ob- 
ject that represents the given item. Calling this in- 
terface's GetIconLocation method then gets direc- 
tions for where to load the icon from. 

The input to GetUIObjectOf is a binary pack- 
aging of the item's basic characteristics, which I'll 
refer to collectively as the item ID. The important 
ones for our purposes are: a pathname to the CPL 
module that hosts the item; an index for the item's 
icon among the module's resources; and a display 
name for the item. The case of interest is that when 
the icon index is zero, the icon is not cached from 
any prior execution of the CPL module, but is to 
be resolved dynamically, i.e., by asking the CPL 
module. Proceeding to GetIconLocation causes the 
CPL module to be loaded, called and unloaded. 

This is all by design. It's a design with more 
moving parts than some would like, especially for 
just this one objective. But it fits the generality of 
shell folders so that highly abstracted and widely 
varying shell folders can present a broadly consis- 
tent user interface, while meeting a particular goal 
for the Control Panel. It's what lets a Control Panel 
item, or a shortcut to one, change its icon according 
to the current state of whatever the item exists to 
control. 

I stress this because more than a few commenta- 
tors blame the vulnerability on what they say was a 
bad design decision decades ago to load icons from 
DLLs, as if this of itself risks getting the DLL to 
execute. What happens is instead much more spe- 
cific. Though CPL modules are DLLs and do have 
icons among their resources, the reason a CPL mod- 
ule may get executed for its icon is not to get the 





22 Although parser bugs have a special place in Pastor’s heart, it’s good to be reminded occasionally that not every bug is a 
parser bug, and that there are other buggy things besides parsers! —PML 
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icon but to ask explicitly which icon to get. 

Note that I have not tied down who calls 
GetUIObjectOf or where the item ID comes from. 
The usual caller is SHELL32 itself, as a consequence 
of opening the Control Panel, e.g., in the Windows 
Explorer, to browse it for items to show. Each item 
ID is in this case being fed back to the class, having 
been produced by other methods while enumerating 
the items. In Stuxnet's exploit the caller is again 
SHELL32, but in response to browsing a shortcut to 
one Control Panel item. The item ID is in this case 
parsed from a shortcut (.LNK) file. Another way the 
call can come from within SHELL32 is automatically 
when starting the shell if a Control Panel item has 
been pinned to the Start Menu. The item ID is in 
this case parsed from registry data. More generally, 
the call can come from just about anywhere, and the 
item ID can come from just about anywhere, too. 





One thing is common to all these cases, however, 
because the binary format of this item ID is docu- 
mented only as being opaque to everyone but the 
Control Panel. If everyone plays by the rules, any 
item ID that the Control Panel's GetUIObjectOf 
ever receives can only have been obtained from some 
earlier interaction with the Control Panel. (Though 
not necessarily the same Control Panel!) 





Input Validation 


As security researchers, we've all seen this movie 
before—in multiple re-runs, even. Among the lax 
practices that were common once but which we now 
regard as hopelessly naive is that a program trusts 
what it reads from a file or a registry value, etc., on 
the grounds that the storage was private to the pro- 
gram or anyway won't have gotten messed with. Not 
very long ago, programs routinely didn't even check 
that such input was syntactically valid. Nowadays, 
we expect programs to check not just the syntax of 
their input but the meaning, so that they are not 
tricked into actions for which the present provider 
is not authorised (or ought to not even know how to 
ask). 

For the Control Panel, the risk is that even if 
the item ID has the correct syntax what actually 
gets parsed from it may be stale. The specified 
CPL module was perhaps registered for execution 
some time ago but isn't now. Or, perhaps, it is still 
registered, but only for some other user or on some 
other computer. And this is just what can go wrong 


even though all the software that's involved plays 
by the rules. As hackers, we know very well that 
not all software does play by the rules, and that 
some deliberately makes mischief. That the format 
of the item ID is not documented will not stop a 
sufficiently skilled reverse engineer from figuring it 
out, which opens up the extra risk that an item ID 
may be confected. (Stick with me on this, because 
we'll do it ourselves later.) 








Asking which icon to show for a Control Panel 
item gives an object-lesson in how messy the 
progress towards what we now think of as minimally 
prudent validation can be. Not until Windows 2000 
did the Control Panel implementation make even 
the briefest check that an item ID it received was 
syntactically plausible. Worse, even though Win- 
dows NT 4.0 had introduced a second format, to 
support Unicode, it differentiated the two without 
questioning whether it had been given either. When 
the check for syntax did come, it was only that the 
item ID was not too small, and that the icon index 
was within a supported range. 


Checking that the module's pathname and the 
item's display name, if present, were actually null- 
terminated strings that lay fully within the received 
data wasn't even attempted until Windows 7. I say 
attempted because this first attempt at coding it 
was defective. A malformed item ID could induce 
SHELL32 to read a byte from outside the item ID— 
only as far as 10 bytes beyond, and thus unlikely 
to access an invalid address, but outside nonethe- 
less. Even a small bug in code for input validation 
is surely not welcome, but what I want to draw at- 
tention to is that this bug conspicuously was not 
addressed by the fix of CVE-2010-2568. A serious 
check of the supposed strings in the item ID came 
soon, but not, as far as I know, until later in 2010 
for Windows 7 SP1. 


Please take this in for a moment. While Mi- 
crosoft worked to close off the spoof by having 
GetUIObjectOf check that the CPL module as 
named in the item ID is one that can be allowed 
to execute, Microsoft described the vulnerability as 
a parsing error—yet did nothing about errors in pre- 
existing code that checked the item ID for syntax! 
Wouldn't you think that if you're telling the world 
that the problem is a parsing error, then you'd want 
to look hard into everything nearby that involves 
any sort of parsing? 

The suggestion is strong that Microsoft's talk of 


23T wonder what would happen if programmers got in the habit of taking the right approach —pitchforks applied to the protocol 


a parsing error was only ever a sleight of hand. As 
programmers, we've all written code with parsing 
errors. So many edge cases!?? To have such an er- 
ror in your otherwise well-written code is only in- 
evitable. Software is hand-crafted, after all. To talk 
of a parsing error is to appeal to the critics’ recogni- 
tion of fallibility. A parsing error can be the sort of 
an easy slip-up that gets you a 99 instead of a 100 
on a test. 

Falling for a spoof, however, seems more like a 
conceptual design failure. It's only natural that Mi- 
crosoft directed attention to one rather than the 
other. My only question for Microsoft is how de- 
liberate was the misdirection. Why so many se- 
curity researchers went along with it, I won't ever 
know. This, too, is a conceptual failure——and not 
just mine. 


First Fix 


Still, it's a plus that fixing CVE-2010-2568 meant 
not only getting the item ID checked ever so slightly 
better for syntax, but also checking it for its mean- 
ing, too. Checking, however, is only the start. What 
do you do about a check that fails? 

Were it up to me, thinking just of what I'd like 
for my own use of my own computer, I'd have all 
CControlPanelFolder methods that take an item 
ID as input return an error if given any item ID 
that specifies a CPL module that is not currently 
registered. My view would be that even if the item 
ID is only stale rather than confected (keep read- 
ing!), then wherever or whenever the specified CPL 
module is or was registered, it's not registered now 
for my use on this computer—and so it shouldn't 
show if I browsed the Control Panel. I'd rather not 
accept it for any purpose at all, let alone run the 
risk that it gets executed. 

Microsoft's view, whether for a good reason or 
bad, was nothing like this firm. First, it regarded 
the problem case as more narrow, not just that the 
specified CPL module is not currently registered (so 
that the item ID is at least stale, if not actually 
faked), but also that the specified icon index is zero 
(this being, we hope, the only route to unwanted ex- 
ecution) and anyway only for GetUIObjectOf when 
queried for an IExtractIcon interface. Second, the 
fix didn’t reject but sanitised.?^ It let the problem 
case through, but as if the icon index were given as 














designers—to address the root cause of these edge cases. —PML. 


-1 instead of 0. 


Perhaps this relaxed attitude was motivated just 
by a general (and understandable) desire for the 
least possible change. Perhaps there was a known 
case that had to be supported for backwards com- 
patibility. I can’t know either way, but what I hope 
you've already woken to is the following contrast be- 
tween rejection and sanitisation. ‘To reject suspect 
input may be more brutal than you need, but it has 
the merit of certainty. The suspect input goes no 
further, and any innocent caller should at least have 
anticipated that you return an error. To “sanitise” 
suspect input and proceed as if all will now be fine 
is to depend on the deeper implementation—which, 
as you already know, had not checked this input for 
itself! 





What Lies Beneath 


By deeper implementation I mean to remind you 
that GetUIObjectOf is just the entry point for ask- 
ing which icon to show. There is still a long, long 
way to go: first for the temporary object that sup- 
plies the GetIconLocation method for the given 
item; and then, though apparently only if the pre- 
ceding stage has zero for the icon index, to the more 
general support for loading and calling CPL mod- 
ules. Moreover, this long, long way goes through old, 
old code, with all the problems that can come from 
that. To depend on any of it for fixing a bug, es- 
pecially one that you know real-world attackers are 
probing for edge cases, seems—at best—foolhardy. 





To sense how foolhardy, let's have some demon- 
strations of where this deeper implementation can 
go wrong. An attacker whose one goal is to see 
if the first fix can be worked around would most 
easily follow the execution from GetUIObjectOf 
down. Many security researchers would follow, too— 
perhaps mumbling that their lot is always to be re- 
acting to the attackers and never getting ahead. One 
way to get ahead is to study in advance as much of 
the general as you can so that you're better pre- 
pared whenever you have to look into the specific. 
This is why, when I examine what might go wrong 
with trying to fix CVE-2010-2568 by letting sani- 
tised input through to the deeper implementation, 
I work in what you may think is the reverse of the 
natural direction. 





24 When neighbors whose software you'd like to trust tell you proudly that they “sanitize” input and "fix" it, so that inputs 
coming in as invalid would still be used—run. You'll thank us later. —PML 


Loading and Calling 


Where we look at first into the deeper implementa- 
tion is therefore the general support for loading and 
calling of CPL modules, but particularly of a CPL 
module that hosts a Control Panel item whose icon 
is to be resolved dynamically. For my 2010 article, 
I presented such a simple example.?? 

Whenever this CPL module is loaded, the first 
call to its exported CP1Applet function produces a 
message box that asks “Did you want me?", and 
whose title shows the CPL module's pathname. 
That much is done so that we can see when the 
CPL module gets loaded. What makes this CPL 
module distinctively of the sort we want to under- 
stand is that when we call to CPlApplet for the 
CPL INQUIRE message, the answer for the icon in- 
dex is zero. 





Install There are several ways to register a 
CPL module for execution, but the easiest is done 
through——wait for it—the registry. Save the CPL 
module as test.cpl in some directory whose path, 
for simplicity and definiteness, contains no spaces 
and is not ridiculously long. Then create the follow- 
ing registry value shown in Figure 9. 





To test, open the Control Panel so that it shows 
a list of items, not categories, and confirm that you 
don't just see an item named Test, but also see its 
message box. Yes, our CPL module gets loaded and 
executed just for browsing the Control Panel. In- 
deed, it gets loaded and executed multiple times. 
(Watch out for extra message boxes lurking behind 
the Control Panel.) Though it's not necessary for 
our purposes, you might, for completeness, confirm 
that the Test item does launch. When satisfied with 
the CPL module in this configuration as a base state, 
close any message boxes that remain open, close the 
Control Panel, too, and then try a few quick demon- 
strations. 

By the way— say it as if it's incidental, even 
though I can't stress it enough—two of these demon- 
strations begin by varying the circumstances as even 
a novice mischief-maker might. Each depends on a 
little extra step or rearrangement that you might 
stumble onto, especially if your experimental tech- 
nique is good, but which is very much easier to add 
if its relevance is predicted from theoretical analysis. 





If you doubt me, don't read on right away, but in- 
stead take my cue about putting spaces in the path- 


25unzip pocorgtfoi4.pdf CPL/testcpl.zip 
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name and see how easily you come up with suitably 
quirky behaviour. Of course, theoretical analysis 
takes hours of intensive work, and often comes to 
nothing. There’s a trade-off, but for investigating 
possibly subtle interactions with complex software 
the predictive power of theoretical analysis surely 
pays off in the long run. 

But enough of my pleas to the computer security 
industry for investing more in studying Windows! 
Let us get on with the demonstrations. 


Default File Extension? First, remove the file 
extension from the registry data. Open the Con- 
trol Panel and see that the Test item no longer 
shows. Close the Control Panel. Rename test.cp1l 
to test.dll. Open the Control panel and see that 
there's still no Test item. Evidently, neither .cpl 
nor .dll is a default file extension for CPL mod- 
ules. Close the Control Panel. Why did I have you 
try this? Create path\test itself as any file you like, 
even as a directory. Open the Control Panel. Oh, 
now it executes test.dll! 

Yes, if the pathname in the registry does not have 
a file extension, the Control Panel will load and ex- 
ecute a CPL module that has .d11 appended, as if 
.d11 were a default file extension—but only if the 
extension-free name also exists as at least some sort 
of a file-system object. Isn't this weird? 


Spaces For our second variation, start undo- 
ing the first. Close the Control Panel, remove 
the subdirectory, and rename the CPL module to 
test.cpl. Then, instead of restoring the registry 
data to *pathNtest.cpl" make it “path\test.cpl 
rubbish." Open the Control Panel. Of course, the 
Test item does not show. Close the Control Panel 
and make a copy of the CPL module as “test .cpl 
rubbish." Open the Control Panel. See first that 
the copy named *test.cpl rubbish" gets loaded 
and executed. ‘This, of course, is just what we'd 
hope. The quirk starts with the next message box. 
It shows that test.cpl gets loaded and executed, 
too! 

Yes, if the registry data contains a space, the 
CPL module as registered executes as expected but 
then there's a surprise execution of something else. 
The Control Panel finds a new name by truncating 
the registered filename—the whole of it, including 
the path—at the first space. And, yes, if the result of 
the truncation has no file extension, then .dll gets 








appended. (Though, no, the extension-free name 
doesn’t matter now.) 

Please find another Zen-friendly moment for tak- 
ing this in. This quirky Wonderland surprise execu- 
tion surely counts as a parsing error of some sort. It 
means that to fix a case of surprise execution that 
Microsoft presented as a parsing error, Microsoft 
trusted old code in which a parsing error could cause 
surprise execution. So it goes. 


Length Finally, play with lengthening the path- 
name to something like the usual limit of MAX_PATH 
characters. That’s 260, but remember that it in- 
cludes a terminating null. Close the Control Panel. 
Make a copy of test.cpl with some long name and 
edit the registry data to match the copy that has 
this long name. Open the Control Panel. Repeat 
until bored. Perhaps start with the 259 characters 
of 


c:\temp\cpltest \1123456789 abcdef2123456789 
abcdef3123456789abcdef4123456789abcdef...f 


123456789 abcde. cpl 





and work your way down—-or start with 


c:\temp\cpltest\test.cpl 9abcdef2123456789 
abcdef3123456789abcdef4123456789abcdef ... f 


123456789 abcdef012 





if you want to stay with the curious configura- 
tion where one CPL module is registered but two get 
executed. (My naming convention is that after the 
16 characters of my chosen path, the filename part 
has each character show its 0-based index into the 
pathname, modulo 16, except that where the index 
is a multiple of 16 the character shows how many 
multiples. The ellipses each hide 160 characters.) 
Either way, for any version of Windows from the last 
decade, the Test item does not show, and the CPL 
module does not get loaded and executed—until you 
bring the pathname down to 250 characters, not in- 
cluding the terminating null. 





Key: 

Value: anything, e.g., Test 

Type: REG_SZ or REG, EXPAND. SZ 
Data: | pathNtest.cpl 


This limit is deliberate. Starting with Windows 
XP and its support for Side-By-Side (SxS) assem- 
blies, the Control Panel anticipates loading CPL 
modules in activation contexts. There are vari- 
ous ways that a CPL module can affect the choice 
of activation context. For one, the Control Panel 
looks for a file that has the same name as the CPL 
module, but with “manifest” appended. Though 
this manifest need not exist, the Control Panel has, 
since Windows XP SP2, rejected any CPL module 
whose pathname is already too long for the mani- 
fest’s name to fit the usual MAX, PATH limit. (The 
early builds of Windows XP just append without 
checking. ‘That they got away with it is a classic 
example of a buffer overflow that turns out to be 
harmless.) 





HKEY CURRENT USERNSoftwareMMicrosoftNWindowsNCurrentVersionNControl Panel\CPLs 


Figure 9. CPL Module Registry Entry 
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The Exec Name 


As we move toward the specifics of loading and call- 
ing a CPL module to ask which icon to show, it’s as 
well to observe that this lower-level code for load- 
ing and calling CPL modules in general is not just 
quirky in some of its behaviors, but also in how it 
gets its inputs. Reasons for that go back to an- 
cient times and persist, so that CPL modules can 
be loaded and executed via the RUNDLL32.EXE pro- 
gram, the lower-level code for loading and calling 
CPL modules that receives its specification of a Con- 
trol Panel item as text——as if it were supplied on a 
command line. For this purpose, the text appears 
to be known in Microsoft’s source code as the item’s 
exec name. It is composed as the module’s path- 
name between double-quotes, then a comma, and 
then the item’s display name. 

Perhaps this comes from wanting to reuse as 
much legacy code as possible. The loading and ex- 
ecuting of a CPL module specifically to ask which 
icon to show for one of that module’s Control Panel 
items—even though this task is no longer ever done 
on its own from any command line—is handled as a 
special case with a slightly modified exec name: the 
module’s pathname, a comma, a (signed) decimal 
representation of the icon index, another comma, 
and the item's display name.?? 

The absence of double-quotes around the mod- 
ule's pathname in this modified exec name is much 
of the reason for the quirky behaviour demonstrated 
above when the pathname contains a space. It goes 
further than that, however. 

I ask you again to take another Wonderland Zen 
moment of reflection. The GetUIObjectOf method 
receives the module's pathname, the item's icon 
index, and the item's display name—among other 
things—in a binary package. It parses them out of 
the package and then into this modified exec name, 
i.e., as text, which the deeper implementation will 
have to parse. What could go wrong with that? 

The immediate answer is that the modified exec 
name is composed in a buffer that allows for 0x022A 
characters, but, until Microsoft's second fix, only 
MAX PATH characters are allowed for the copy that's 
kept for the object that gets created to represent 
the Control Panel item for the purpose of provid- 
ing an IExtractIcon interface. This mismatch of 
allowances is ancient. Worse, even though Windows 
Server 2003 (chronologically, but Windows XP SP2, 








by the version numbers) had seen Microsoft intro- 
duce the mostly welcome StringCb and StringCch 
families of helper routines for programmers to work 
with strings more securely, this particular copying 
of a string was not converted to these functions un- 
til Windows Vista—and even then the programmer 
could blow away much of its point by not checking 
it for failure. 

If the CPL module's pathname is just long 
enough, the saved exec name gets truncated so that 
it keeps the comma but loses at least some of the 
icon index. When the GetIconLocation method 
parses the (truncated) exec name, it sees the comma 
and infers that an icon index is present. If enough 
of the icon index is retained such that digits are 
present, including after a negative sign, then the 
only consequence is that the inferred icon index is 
numerically wrong. If the CPL module's pathname 
is exactly the “right” length, meaning 257 or 258 
characters (not including a terminating null), then 
the icon index looks to be empty or to be just a 
negative sign, and is interpreted as zero.?" 

It's time for another of those Wonderland mo- 
ments. To defeat a spoof that Microsoft misrep- 
resented as a parsing error, Microsoft dealt with a 
suspect zero by proceeding as if the zero had been 
-1, but then an actual parsing error in the deeper 
implementation could turn the -1 back to zero! 

The practical trouble with this parsing error, 
which is perhaps the reason it wasn't noticed at the 
time, is that it kicks in only if the CPL module's 
pathname is longer than the 250-character maxi- 
mum that we demonstrated earlier. An item ID that 
could trigger this parsing error isn't ever going to be 
created by the Control Panel. It can't, for instance, 
get fed to GetUIObjectOf from a shortcut file that 
we created simply by a Ctrl-Shift drag. If we want 
to demonstrate this parsing error without resorting 
to a Windows version that’s so old that the Control 
Panel doesn’t have the 250-character limit, the item 
ID would need to be faked. We need a specially 
crafted shortcut file after all. 


Shortcut Crafting Making an uncrafted short- 
cut file is straightforward if you’re already familiar 
with programming the Windows shell. The shell 
provides a creatable COM object for the job, with 
interfaces whose methods allow for specifying what 
the shortcut will be a shortcut to, and for saving 


26 At this point, you might feel exactly how Alice felt in Wonderland. The Cheshire Cat would approve. —PML 
27 And now we don’t even need to ask what the Caterpillar was smoking. —PML 
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the shortcut as a .LNK file. The target, being an 
arbitrary item in the shell namespace, is specified 
as a sequence of shell item identifiers that generalise 
the pathname of a file-system object. To represent 
a Control Panel item, we just need to start with 
a shell item identifier for the Control Panel itself, 
and append the item ID such as we've been talk- 
ing about all along. Where crafting comes into it is 
that we've donned hacker hats, so that the item ID 
we append for the Control Panel item is confected. 
But enough about the mechanism! You can read the 
source code.?? 

To build, use the Windows Driver Kit (WDK) 
for Windows 7. 'The 32-bit binary suffices for 64- 
bit Windows. You may as well build for the oldest 
supported version, which is Windows XP, but the 
program does nothing that shouldn't work even for 
Windows 95. 

To test, open a Command Prompt in some 
directory, e.g., path, where you have a copy of 
test.cpl from the earlier demonstrations of gen- 
eral behaviour. Again, for simplicity and definite- 
ness, start with a path that contains no spaces and 
is not ridiculously long. To craft a shortcut to what 
might be a Control Panel item named Test that's 
hosted by this test.cpl, run the command 





os ee em ars -——MMM meme NI eee eee recs 
1| linkcpl /module: path\test.cpl /icon:0 /name: 
Test test.Ink 





With the Windows Explorer, browse to this same 
directory. If running on an earlier version than Win- 
dows 7 SP1 without Microsoft’s first fix, you should 
see the CPL module’s message box even without 
having registered test.cpl for execution. For any 
later Windows version or if the first fix is applied, 
browsing the folder executes the CPL module only 
if it’s been registered. 

For full confidence in this base state, re-craft the 
shortcut but specify any number other than zero 
for the icon index. Confirm that browsing does not 
cause any loading and executing unless the short- 
cut records that the CPL module is of the sort that 
always wants to be asked which icon to show. 








Very Long Names The point to crafting the 
shortcut is that we can easily use it to deliver to 
GetUIObjectOf an item ID that we specify in detail. 
Do note, however, that the shortcut is only conve- 
nient, not necessary. We could instead have a pro- 
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gram confect the item ID, feed it to GetUIObjectOf 
by calling directly, and then call GetIconLocation 
and report the result. 

Either way, the details that we want to spec- 
ify are the module's pathname and the icon index. 
We'll provide pathnames that are longer than the 
Control Panel accepts when enumerating Control 
Panel items, but which nonetheless result in the ex- 
pected loading and execution when the icon index is 
zero. Then, we'll demonstrate that when the path- 
name is just the right length, as predicted above, 
the loading and execution happen even when the 
icon index is non-zero. The assumption throughout 
is that the Windows you try this on does not have 
Microsoft's second fix. 

We know anyway not to bother with the very 
longest possible name (except as a control case), 
since the truncation loses the comma from the exec 
name such that it will seem to have no icon index 
at all. Instead make a copy of test.cpl that has a 
258-character name such as 


c:\temp\cpltest \1123456789 abcdef2123456789 
abcdef3123456789abcdef4123456789abcdef... f 


123456789abcd. cpl 





Craft a /icon:0 shortcut that has this same long 
name for the module’s pathname. If testing on a 
Windows that has the first fix, also edit this long 
name into the registry. Browse the directory that 
contains the shortcut—and perhaps be a little dis- 
appointed that the CPL module does not get loaded 
and executed. 

But now remember that delicious quirk in which 
a space in the module’s pathname, within the 250- 
character limit, induces the loading and executing of 
two CPL modules, first as given and then as trun- 
cated at the first space. Copy test.cpl as 


c:\temp\cpltest\test.cpl 9abcdef2123456789 
abcdef3123456789abcdef4123456789abcdef... f 


123456789 abcdef0l 
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Re-craft the shortcut by giving this name to the 
/module switch in quotes. Update the registration 
if appropriate. Still, the copy with the long name 
doesn't get loaded and executed——but, as you might 
have suspected, the copy we've left as test.cpl 
does! Indeed, because the copy with the long name 





Sunzip pocorgtfoi4.pdf CPL/linkcplsrc.zip CPL/linkscplbin.zip 


doesn’t have to execute for this purpose, and be- 
cause its Control Panel item won't show in the Con- 
trol Panel, it doesn't need to be a copy. Even an 
empty file suffices! 


Edge Cases By repeating with ever shorter path- 
names, but also trying non-zero values for the icon 
index, we can now demonstrate that CVE-2010-2568 
has its own edge cases, as predicted from theoretical 
analysis. The general case has zero for the icon in- 
dex. The edge cases are that if the pathname is very 
long but contains a space in the first 250 characters, 
then the icon index need not be zero. The following 
table summarises the behaviour on a Windows that 
does not have CVE-2010-2568 fixed. 

The length does not include a terminating null. 
The icon index is assumed to be syntactically valid: 
negative means OxFF000000 to OxFFFFFFFF in- 
clusive; positive means 0x00000001 to OxOOFFFFFF 
inclusive. Execution is of the CPL module that is 
named by truncating the very long pathname at its 
first space. (Also, if this has no file extension, ap- 
pending .d11 as a default.) 


Length Icon Index Exec? Remarks 

259 Any No 

25g Zero Yes 
Non-Zero Yes Edge Case 
Zero Yes 

257 Negative Yes Edge Case 
Positive No 

Less Zero Yes If Registered”? 
Non-Zero No 


CV E-2015-0096 


The point to Microsoft’s first fix of CVE-2010-2568 
was to avoid execution unless the pathname in the 
item ID was that of a registered CPL module. But 
the decision to test the registration only if the icon 
index in the item ID was zero meant that the two 
edge cases were completely unaffected. Worse, when 
the icon index in the item ID was zero, changing the 
zero to —1 would turn the suspect item ID not into 
something harmless but into an edge case. Either 
way, the pathnames had to be so long that the edge 
cases turned into surprise execution only because of 


29Since the first fix, this executes only if registered. 
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a quirk even deeper into the code such that the CPL 
module executes needed not to be the one specified. 

CVE-2015-0096 appeared to be the first public 
recognition of this, not that you would ever guess it 
from the formal description or from anything that I 
have yet found that Microsoft has published about 
it. From Dave Weinstein's explanation, it appears 
that the incompleteness of the first fix was found by 
following the mind of an attacker frustrated by the 
first fix and seeking a way around it. 

The second fix plausibly does end the exploitabil- 
ity, at least for the purpose of using shortcuts to 
Control Panel items as a way to spread a worm. 
The edge cases exist only because of a parsing error 
caused by a buffer overflow. The second fix increases 
the size of the destination buffer so that it does not 
overflow when receiving its copy of the exec name. 
For good measure, it also tracks the icon index sep- 
arately, so that it anyway does not get parsed from 
that copy. 

But the CPL module's filename continues to be 
parsed from that copy. If it contains a space, then 
the Control Panel still can execute two CPL mod- 
ules, one as given and one whose name is obtained 
by truncating at the first space. Only because of this 
were the edge cases ever exploitable. Yet even as late 
as the original release of Windows 10—which is as 
far as I have yet caught up to for my studies—it re- 
mains true that if you can register “path\test.cpl 
rubbish" or “path\space test.cpl” for execution 
as a CPL module, then you can get path\test.cpl 
or pathNspace.dll loaded and executed by sur- 
prise. Is anyone actually happy about that? 

Many ways seem to lead into this Wonderland, 
but is there a way out? 

















14:09 Postscript that shows its own MD5 


Introduction 





Playing with file formats to produce unexpected re- 
sults has been a hacker past-time for quite a while. 
These odd results often include self-referencing code 
or data structures, such as zip bombs, self-hosting 
compilers, or programs that print their own source 
code-called quines. Quines are often posed as brain 
teasers for people learning new programming lan- 
guages. 

In the light of recent attacks on the crypto- 
graphic hash functions MD5 and SHA-1, it is natural 
to ask a related question: Is there a program that 
prints out its own MD5 or SHA-1 hash? A similar 
question has been posed on Twitter by Melissa.?? 


i: 


Trick | want to see: a document in a 





Melissa Ê 
Oxabad1dea 


conventional format (such as PDF) which 
mentions its own MD5 or SHA1 hash in the text 
and is right 


8:55AM 9 Aug 2013 





The original tweet is from 2013. It appears that 
since then nobody provided a convincing solution 
because in March 2017 Ange Albertini declared that 
the challenge was still open. This brought the prob- 
lem to my attention—the perfect little Sunday morn- 
ing challenge. 





A Bit of Context 


Melissa's challenge asks whether there is a document 
in a conventional format that prints its own MD5 
or SHA-1 hash. At the first glance this question 
might appear to be a bit stronger than the question 
for a program that prints its own MD5 or SHA-1 
hash. However, it is well known that several doc- 
ument formats actually allow for Turing-complete 
computations. Proving the Turing-completeness of 
exotic programming languages (such as Postscript 
files or the x86 mov instruction) is in fact another 
area that appears to attract the attention of sev- 
eral hackers. Considering that Postscript is Turing- 


PÜhttps: / /twitter.com /Oxabad1dea/status /365863999520251906 
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by Gregor “Greg” Kopf 


complete, could build à program that prints out its 
own MD5 or SHA-1 hash? 


The problem of building such à program can be 
viewed from (at least) two different angles. One 
could view this hypothetical program as a modified 
quine: instead of printing its own source code, the 
program prints the hash of its own source code. If 
you are familiar with how quines can be generated, 
you can easily see that the following program is in- 
deed a solution to the question: 





'n-chr (10) ’ 


a—['from hashlib import *’, 
'print md5("a="+str (a) 
+n+n.join(a)-+n) 


.hexdigest()’] 

from hashlib import x 

n=chr (10) 

print md5("a="+str(a)+n4n. join(a)+n). 
hexdigest () 





While this method can likely be applied to 
Postscript documents as well, I did not like it very 
much. Computing the MD5 hash of the program at 
runtime felt like cheating. 

The desired file is a modified fixpoint of the used 
hash function, in the same sense that this program 
is a modified quine. A plain fixpoint would be a 
value z where x = h(x). Here, h denotes the hash 
function. This problem has not yet, so far as I know, 
been solved constructively. (Statistics reveals that 


such fixpoints exist with a certain probability, how- 
ever. ) 
IW Tubular 1 
n Driving 
— Lamp ; 
IT burns ker much les i 
(8 Send for Book. $ 


Special Offer . 
R. E. DIETZ CO., 60 Laight Street, New York 
A 4342 3448 48D 











"y 


























ul e on y bns aiii pe p perfect 
iving oa 
IT s ne ot dem 
IT vives a clear 
IT looks i ke + ie Oti ene adlight. 
IT thr ai? ches lig "s straight a ahe ad 
from 200 to A » feet. single Lamp 


nor jar « 
es d li - CUT THIS AO TED oup 
and send to us and we will s sai des 

ing our La ie ind wil agree 

1 pair at our tice ori stes ery 


ss Da n ‘the retail price). 





But there is another—even simpler—trick one can 
perform given the ability to create colliding MD5 in- 
puts. One can create two executables with the same 
MD35 hash but with different semantics. The general 
idea is to generate two colliding MD5 inputs a and 
b. We can then write a program like the following. 


“Dr, Scott’s Electric” 


goods are world renowned for the beneficent power of 
Electro-Magnetism they contain, and popular because this 
curative agent is combined in articles of every-day use. 


Electric Corsets Cure Weak Back, Indi- 


gestion, Spinal Trouble, 
Rheumatism. Price, $r. $1.50, $2.00, and $3. 





















? 


print 'Hi, my message is: 
Lf === qs 
print "Hello World" 





else: 
print "Oh noez, I've been hacked!!1" 





Electric Hair Brushes $e 


ness, Dandruff, and Diseases of the scalp. Price, $1.00, 


$1. o 2.00, vis 50, and $3.00. 
cure Rheumatism, Nervous 


Electric Belts Debilit y, Indigestion, Back- 


ache, Liver and Kidney Trouble. Price, $3.00, $5.00, 
and $10. 00. | 








And another program like this: 






? 


print 'Hi, my message is: 
If b-p 
print "Hello World" 


















else: 
print "Oh noez, I’ve been hacked!!1" 


a safeguard 
Electric Safety TTE B er 
ber's Itch, Pimples, and Blotches ; perfect security from. 
cutting the face when shaving. ' À novice can use it. 
Price, — 00. 








Both programs will have the same MD5 hash; in 
the second program, we only replaced a with b. 

But why does this work? There are two things 
one needs to pay attention to. Firstly, we have to 
understand that while the inputs a and b might col- 
lide under MD5, the strings "foo" +a and "foo" +b 
may not necessarily collide. Fortunately, Wang’s at- 
tack allows us to rectify this. The attack does not 


orn 9 e © e © e 9/0 © @ © ec only generate colliding MD5 inputs, it also allows to 
obi Ili dz P | T bl generate collisions that start with an arbitrary com- 
i lar 00 a eso mon prefix. (This is what the term chosen-prefix 


Cues, Bowling Alleys and everything needed 


SX 
ELECTRIC PLASTERS, INSOLES, 
FLESH BRUSHES, TOOTH BRUSHES, | 
CURLERS, AND APPLIANCES. 









If you cannot obtain these goods at the store, we will send them, post- 
paid, on receipt of the price. Our book, * The Doctor's Story," giving 
full information concerning all our goods, free on application. Address 


GEO. A. SCOTT, 
Room 5, 846 Broadway, NEW YORK. 
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Col/elelele%el/e® | 


1l print 'Hi, my message is: 


Fortunately, we are looking for something a lit- ii 
tle easier. We are looking for an «x that satis- 
fies x = encode(h(x)) for some encoding function 
encode(). I decided to chase this idea: constructing Secondly, we also need to keep in mind that in 
such a value x, using MD5 as hash function h() and our programs we have appended some content af- 
a function that builds a Postscript file as encode(). ter the colliding data. Fortunately, as MD5 is a 


Merkle-Damgárd hash, given two colliding inputs a 
and b, the hashes MD5(a + xz) and MD5(b + x) will 
The Basics also collide for all strings x. This property allows 


us to append arbitrary content after the colliding 
When Wang et al., broke MD5 in 2005, there was blocks: 


considerable interest in what one could do with a 
chosen-prefix MD5 collision attack. Sotirov et al., 
have demonstrated in 2008 that one could exploit 
Wang’s work in order to build a rogue X.509 CA 
certificate—the final nail in MD5’s coffin. 


AT 


Constructing the Target 


Using the above technique allows us to encode a sin- 
gle bit of information into a program without chang- 
ing the program’s MD5 hash. Can we also encode 
more than one bit into such a program? Unsurpris- 
ingly, we can! 

We start the same way that we have already seen, 
by generating two MD5 collisions a and b that share 
the following prefix. 


' Hey, 


print I can encode multiple bits!" 


This allows us to build two colliding programs 
that look like the following. (Exchange a with b to 
get the second program.) 


print "Hey, 
result = || 
if a — b: 
result .append (0) 
else: 
result .append (1) 


I can encode multiple bits!’ 


And from here, we simply iterate the process, 
computing two colliding MD5 inputs c and d that 
share this prefix. 





print ’Hey, 
result = || 
if à — b: 
result .append (0) 
else: 
result .append (1) 


I can encode multiple bits!’ 


This allows us to build a program with two bits 
that might be adjusted without changing the hash. 


print ’Hey, 
result = || 
if a == b: 
result 
else: 
result 


I can encode multiple bits!’ 


. append (0) 
. append (1) 


if ¢ = d: 
result .append (0) 
else: 
result 


. append (1) 
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We can replace a with b, and we can replace c 
with d. In total, this yields four different programs 
with the same MD5 hash. If we add a statement like 
print result at the end of each program, we have 
four programs that output four different bit-strings 
but share a common MD5 hash! 

How does this enable us to generate a program 
that outputs its own MD5 hash? We first generate a 
program that we can encode 128 bits into. Knowing 
that the MD5 hash of this program will not change 
independently from what bits we encode into the 
program. Therefore, we simply encode the 128 out- 
put bits of MD5 into the program without altering 
its hash value. In other words, the program prints 
the 128 output bits of its own hash value. 





Application to Postscript 


This technique can directly be applied to Postscript 
documents as Postscript is a simple, stack-based lan- 
guage. Please consider the following code snippet. 


ae DS-CAPS l 


$89?" 


A Unique Keyboard 

or Program Activated 
Data Switch for the 
IBM PC or Any MS-DOS 
System. 


 DS-CAPS 
: Data Switch 


This compact self-powered switch is soft- 
ware controlled at the keyboard or pro- 


gram to direct parallel data from the 
computer to printers/plotters. Eliminates 
the time and frustration of recabling to use 
different peripherals. To install, connect 
between computer and peripherals, plug 
into power, boot supplied software disc 
and you are ready to code select and 
direct data flow between the two devices. 


VIA WEST, lac. 


The interface Company 
534 North Stone Ave., Tucson AZ 85705 
(602} 623-5716 


É COMPUTER 


: PRINTERS 





58"x3.8"x1.0" 


Also available is a complete line of manual 
and electronic switches plus converters to 
interface and direct data between CPUs 
and peripherals. 


*All units shipped freight-collect. Add $4.00/unit for 
Postpaid delivery. Checks, VISA or MasterCard accepted 
Quanuty discounts available. AZ residents add 7%. 
Deater inquires invited. 


Trademarks: IBM & IBM PC-International Business Machines Corp./ MS-DOS-Microsoft Corp. 





While this may look a bit cryptic, the program 
is in fact very simple. It compares the string literal 
“a” to the string literal “b”, and if both strings are 
equal, it pushes the numeric value 1 to the stack. 
Otherwise, it pushes a 0. 

This examples highlights the manner in which we 
can build a Postscript file that we encode 128 bits 
of information into without changing the file’s MD5 





hash. ‘The program will push these desired bits to 
the stack. We can extend this program with a rou- 
tine that pops 128 bits off the stack and encodes 
them in hex. To demonstrate the feasibility of this 
idea, we can inspect how one nibble of data would 
be handled by this routine. 





Slunzip pocorgtfoi4.pdf md5.ps 


This code excerpt will pop four bits off the stack. 
If all bits are zero, the string literal “0” will be 
pushed onto the stack. If the lowest bit is a one and 
all other bits are zero, the string literal “1” will be 
pushed, etc. The show statement at the end causes 
the nibble to be popped off the stack and written to 
the current page. 

An example of such a Postscript document is 
included in the feelies?! If you want to build 
such a document on your own, you could use the 
python-md5-collision library?? to build MD5 col- 
lisions with chosen prefixes. 
$ md5sum poc.ps 
768d9d89d2bc825a319eb8962ad30580 poc.ps 


Be -coEM 
File Edit Options View Orientation Media Help 


CS) il? id) «| >) €|| CY IIS 


poc - GSview 


Closing Remarks 


We have seen two approaches for generating pro- 
grams that print out their own hash values. The 
quine approach does not require a collision in the 
used hash function, however this comes at the cost 
of language complexity. In order to build such a 
modified quine, the chosen language must allow for 
self-referencing code as well as computing the se- 
lected hash function. 

The fixpoint approach is computationally more 
expensive to implement, as several hash collisions 
must be computed. However, these hash calcula- 
tions can be performed in any programming envi- 
ronment. With this approach, the target language 
can be comparably simple: it just needs condition- 
als, string comparison and some method to output 
the result. 


32git clone https://github.com/thereal1024/python-md5-collision 
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14:10 A PDF That Shows Its Own MD5 


Even though MD5 is quite broken, you might 
easily assume that creating a file that contains its 
own MD5 is impossible. After all, surely changing 
the file would change its MD5? Let's honor this 
publication’s fine history of PDF tricks by creating 
a PDF file that displays its own MD5 hash when 
viewed. 


ʻO: Each of these nibble elements (pictures, text) 
ZE is crafted to collide with the others: 
EAD —> swapping them preserve the hash. 





All displayed nibbles of the hash can be changed 
to match the file's hash while keeping the same hash. 


Each hash nibble is a reference to a distinct element: 
— their value is stored in specific areas of the file 
where the collisions can be crafted. 


Our tactic will be to make each digit of the MD5 
checksum a separate JPEG image, and make the 
MD35 hashes of all 16 possible images collide to the 
same value. We can then swap out images to display 
any combination of digits without affecting the file's 
MD5. This requires 15 collisions per digit, and since 
they depend on the MD5 of the preceding part of the 
document, we need to do this for each digit, for a to- 
tal of 15 x 32 — 480 collisions. With a few compute- 
months of power we could just append chosen-prefix 
collisions to whatever images we liked and be done 
with it, but that's too slow. If we could make do 
with faster shared-prefix MD5 collisions — for exam- 
ple Marc Stevens’ Fastcoll?? — we could be finished 


in an hour. 


Craft file structure: 
1 each hash nibble is a reference to a specific element 
where the collisions will happen. 





Compute collisions for all 16 values for the 1st nibble 
(abusing file formats, based on the current file prefix). 


---r--r- 


Do the same for the 2nd nibble... 
(the prefix contains the first nibble area now 


) 2nd nibble 


..and so on, for each nibble of the hash 
(32 in the case of MD5). 


X |. 1 Change all nibbles to match the actual file hash. 


Footer 





33unzip pocorgtfo14.pdf fastcoll-v1.0.0.5-1.zip 


by Mako 


This adds some restrictions. Everything other 
than the pairs of collision blocks must now be the 
same. Furthermore, the two versions of the first col- 
lision block have a fixed relationship, as shown in 
Figure 10. 

If we could only get one of those bits to be in the 
length field of a JPEG comment marker, we could 
take loving inspiration from Ange Albertini’s trick in 
the SHAttered attack, colorfully explained by Hec- 
tor Martint in Figure 11, to display two different 
images. 

Unfortunately, they’re in the middle of the colli- 
sion block, and worse, those message words are being 
used to satisfy these constraints on Q[5], Q[12] and 


Q[15]:5 


Q[5] = 01000701 11111111 11111111 11^^10^^ 
9QL12] 9010... 20-2 20i scl S 
QES SOs Oech, ME ene eee nts 


. is don’t-care, 
^ is same as previous Q, 
! is inverted from previous Q. 


Hmmm. Q|15| is pretty lightly con- 
strained. Maybe we could just set m|l4|] = 
(m|14]&0xff000000)|0x01feff and see what it does 
to Q[15]. That'd give a JPEG comment of length 
256-383 bytes on one side and 128 bytes longer on 
the other, and we can try just generating new sets of 
values until they meet the constraints. Luckily this 
works often enough to be practical, though there 
are probably more elegant approaches. 

Now we can start colliding JPEGs! The struc- 
ture is quite simple: we begin with an FF D8 start- 
of-image marker and the parts that are identical in 
all our images, such as the JFIF APPO segment, 
then add a JPEG comment that will end at exactly 
byte 56 of our collision block. After padding to a 
64-byte block boundary and creating a collision, we 
finally have two partial files with identical MD5 val- 
ues but different JPEG comment lengths. 

From here it’s straight sailing. In the short- 
comment version, the next JPEG marker parsed is a 


?4See https: //twitter.com/marcan42 /status/835175023425966080 
35 Tf these constraints look like voodoo or hoodoo to you, please unzip pocorgtfoi4.pdf md5-1block-collision. pdf 
stevensthesis.pdf and read Marc Stevens’ papers on how the collisions are formed. Don’t expect to learn all of his magic in 


just a weekend. —PML 


blocky |4| = block, [4| 
blocky |11] = block, 11] 
blocky|14] = block, |1 


+ (1 << 31); 
+ (1 << 15); 
4| 4- (1 << 31); 


(rest of block is unchanged) 


Figure 10. Colliding Block Relationship 


$ hexdump -vC_shattered-1.pdf 
00000000 





T 15 2s 96.. 
PDF Header 


JPEG Start 
JPEG Comment 


Comment length — 


ooo 
ooo 
eo 
eo 


eo 
COOOOOoooooo 


JPEG Comment 


cOOooooooo 
OOOOooooo 
CcOOooooooo 


Desync 
“| JPEG parsing gets f 
out of sync here 


eOoooocoq 
COOOOo00000000205 ood 
Om 2an O90) -I0 1 i UN 


0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
0 
BO 
0 
0 
0 
0 
80 


JPEG Comment 


Real JPEG data starts much later... 


00000310 
00000320 
00000330 
00000340 


JPEG Comment 





apace 7 0 R/Leng 
th 8 0 R/BitsPer 
Component 82». st 


Collision | Boi 


. This is the only part of the 
files which is different 


$ hexdump -vC shattered-2.pdf 
20000010 





%PDF-1.3.%... 
E .«« idt 


PDF Header 


JPEG Start apace 7 0 R/Leng 


8 0 R/BitsPer 


JPEG Comment Component 8>>.st 


ream...... $ 
is deàdiit1!./ 
d 9... Sb reos 
000060d0 E.g....K.Ly..+= 
000000e ra Me Tesa KE Sasis 
00000 oofc Comment length = on M pr 
900€ M t. x02 ivd 
a0.. osse vi 
JPEG Comment POSER OK. 
Mii: NIS800 00 00-62-00-00— |................ 
prede S ure 
Quantization table RS AENEA UE EU 
ENG. PERS 


Interleaving 
Small comment on the 0 f 
right hides the header 
between the two large 
comments on the left 


200320 
00000330 





00000340 


Quantization table 


0) 29) header ecc] |] | |  ] | n n ] 9 n9 n9 


1 J IPEG 3.04 03.0 


Huffman tables FA JPEG Comment FETU CB 


Image data CC BY 4.0 Hector Martin 2017 


Figure 11. How the SHA-1 collision PDF format trick works 


comment skipping past image 0. The long-comment 
version instead sees the contents of image 0 followed 
by another JPEG comment extending right to the 
end of the image, whose size we'll hardcode for con- 
venience. This lets us switch between image 0 and 
the other images without changing the MD5, and 
we repeat this process for images 1, 2, etc. The fi- 
nal image for F is displayed if no other image was 
selected, giving a total of fifteen collisions, repeated 
for each of the thirty-two digits. 


Start Of Image 
APPO segment 


dumped Comment declaration 


byte 56 \ Collision block 


Pls d | “declares a comment 


File 2 of variable length 


9Óunzip pocorgtfoi4.pdf md5jpg.pdf 


ol 


C>md5sum md5jpg.pdf 
71aal3f4b83b424807e3db3260ffe20b *md5jpg.pdf 





= [x] x 





B d | Page: 1/7 49 9| F A P| Fine 


1]nn13FABB83B4Zz4B80 7E3DB3Z60FFEZOB 


Since this doesn't require any clever PDF tricks 
the file?? should work for any PDF, and because the 
image sizes are fixed in advance it could just have 
fixed-size placeholder images that are overwritten by 
the collision. Total running time is approximately 
an hour. 


Alternatively, the PDF format has a feature 
called Form XObjects, effectively embedded mini- 
PDFs which can be displayed using “/objectname 
Do" and can be nested. If we can keep characters 
not allowed in a name out of the MD5 collision we 
can switch which XObjects get drawn and display 
the MD5 as actual text. (Thankfully enough PDFs 
draw text one character at a time that everything 





handles this cleanly.) block[15] is as unconstrained 
as 14 and can become the Do command, meeting the 
(mostly irrelevant) length limit on names in PDFs, 
and avoiding most character restrictions on the sec- 
ond collision block. ‘This turns out to save quite a 
bit of hacking time and runtime. 


ing parentheses to properly terminate the dummy 
strings and keep Adobe Reader happy — but not 
counting escaped parentheses, or we’ll add too many 
closing parentheses and break PDF.js again. 
That’s a lot of extra effort just to make copy- 
and-paste and pdftotext work, with no guarantee 


future software won't break it. It works though.?" 
$ pdftotext -q md5text.pdf - 
66DA5E07COFDAC921679A65931FF8393 


Of course then we have to deal with 
implementation-specific fixes like disguising the 
trailing garbage as a string because PDF. js gives up 
otherwise, banning Ox80 and Oxff which PDFium 
considers whitespace for some reason, and match- 


$ md5sum md5text.pdf 
66da5e07c0fd4c921679a65931ff8393  md5text.pdf 











How we put the MD5 on the Front Cover 


a short addendum by Philippe Teuwen 


On page 56, you'll see that this issue is à NES ROM polyglot that, when run, prints its own MD5 
checksum. It would have been be a pity to not take advantage of the trick presented by Mako to get this 
very issue displaying the same MD5 on its cover page. 

This required some productization of Mako's PoC, moving from a stand-alone Python script that creates 
a PDF from scratch to something that can be integrated with our existing TFX toolchain. 

PdfIEgX provides Npdfximage as a mechanism for embedding graphic objects, which, combined with 
\immediate, allows us to inject the sixteen JPEG tiles at the beginning of the PDF, right after the pseudo 
object containing the bulk of the NES ROM. This mechanism is accessed by means of \pdflastximage and 
\pdfrefximage wherever we want to use the injected tiles: 








\immediate\pdfximage width 4.8pt isupertile.jpg) 
\edef\mdfivetileAA{\kern ipt \pdfrefximage\the\pdflastximage} 
\immediate\pdfximage width 4.8pt {supertile. jpg} 
\edef\mdfivetileAB{\kern ipt \pdfrefximage\the\pdflastximage} 


\edef \mdfivet{\mdfivetileAA{}\mdfivetileAB{}...} 


New tiles have been created to mimic the default XIX monospace font under the constraint that they, 
with the extra colliding blocks, can fit under a single JPEG comment, i.e. a total size fitting in a 16-bit word 
and in fine an average of 3,500 bytes per tile. Alternatively, it would have been possible to include higher 
resolution tiles, at the cost of crafting chained comment blocks. 

To get both NES and title page MD5 right, the operations have to be properly interleaved: compile 
IATEX sources with the \pdfximage objects; integrate the ZIP; insert a first PDF object with the NES 
ROM; insert the ROM header in front of the PDF header; compute the collisions for the ROM; insert a first 
set of collisions in the ROM; compute the collisions for the PDF/JPEG tiles; insert a first set of collisions 
in the PDF /JPEG tiles; compute the complete file MD5; swap collisions in the ROM; swap collisions in the 
PDF /JPEG tiles. 

As we like to see the correct MD5 while typesetting without having to recompute the collisions system- 
atically, we use two caches of the collisions that need to be renewed only if the MD5 of the prefixes change. 
With a little luck, that’s only when the NES ROM or the JPEG tiles are modified. 

Finally, we manually backport the collisions displaying the computed MD5 into the monoglot and inani- 
mate PDF version of the issue provided to the print shop. 


3Tunzip pocorgtfoi4.pdf md5text .pdf 
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14:11 This GIF shows its own MD5! 


The recent successful attack on the SHA-1 hash 
algorithm?? has led to a resurgence of interest in 
hash collisions and their consequences. 

A particularly well-broken hash algorithm is 
MD5, which allows for a myriad of ways to play with 
it. Here, we demonstrate how to assemble an ani- 
mated GIF image that displays its own MD5 hash.?? 
$ md5sum md5.gif 

f5ca4f935d44b85c431a8bf788c0eaca 





md5.gif 
- c 





[A md5.gif (855x203) x 


X 


C | @ Secure | https://shells.aachen.ccc.de/~spq/md5.gif 





The GIF89a file format 


A GIF89a file consists of concatenated blocks. A 
parser can read these blocks from the file in a serial 
fashion without needing to keep state. 

A GIF file is made up of three parts. 


Header Signature, Version and basic info like the 
Canvas Size and (optional) Color Map. 


Body Image, Comment, Text and Extension 


blocks, in any order. 


Trailer The byte 0x3b. 


Of particular interest to us is the format of 
comment blocks. They begin with the two bytes 
Ox21 Oxfe, followed by any number of comment 
chunks. Every chunk consists of one length byte 
and <length> bytes of arbitrary data. The end of 
the comment block is marked with a chunk having 
zero length. 

This means that, by controlling the length 
bytes, we can make the parser skip any number of 
non-displayable bytes in comment chunks. ‘These 
skipped bytes, of course, still affect the file’s MD5 
hash. So two GIF files can show different content, 
while their skipped bytes are manipulated to make 

98unzip pocorgtfoi4.pdf shattered.pdf 


39unzip pocorgtfoi4.pdf md5.gif 
4Ounzip pocorgtfoi4.pdf fastcoll-vi.0.0.5-1.zip 
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by Kristoffer “spq” Janke 


them have the same MD5 hash values. With some 
careful stitching, here we'll build just such files— 
MD35 GIF collision pairs. 


comment label 
(comment extension) 


MD5 collisions 


For MD5, appending the same data to both collid- 
ing files will still produce the same hash value. The 
same is true for appending another collision pair. 5o 
we can have four different files all having the same 
MD5 hash with this method. 

Or, instead of producing multiple files, we can 
produce just one file but later change one of the col- 
lisions in the produced file. This is the technique 
we'll use here. 

Fastcoll is a MD5 collision generator, created 
by Marc Stevens.? From any input file, it gener- 
ates two different output files, both having the same 
MD5 hash. 

These output files consist of the 64-byte aligned, 
zero-padded input file, followed by 128 bytes of col- 
lision data generated by Fastcoll. Every byte from 
the generated collision data of both files appears to 
be random. Comparing these last 128 bytes in both 
output files, we can see that only nine bytes differ. 
These bytes can be found at indices 19, 45, 46, 59, 
83, 109, 110 and 123. While the bytes at 46 and 
110 do not show any pattern, the other bytes differ 
only and exactly in their most significant bit. This 
can be used to construct GIF comment chunks of 
different sizes. 





Showing two different images 


The GIF comment block format and the collisions 
generated by Fastcoll allow for the creation of two 
GIF files that have the same MD5 hash, but are 
interpreted differently. 

By constructing the GIF such that one of the 
differing bytes in the collision data is interpreted as 
the length of a comment chunk, the interpretation 








Fields Values 
signature "GIF" 
Header version "89a" 













flags A1 (01 010 © 001) 
Local screen ecT true 
23456789 ABCDE descriptor E aL 
00:|.G .I .F .8 .9 .a 03 00 01 00 Al 00 00 FF 00 00 udi c Pe 
10: 00 FF 00 00 00 FF FF FF FF|2C 00 00 00 00 03 00 — 00 00 FF FF FF FF 
20: 01 00 00 02 02 44 54 09 [3B 











of the remaining file will be different across the two 
colliding files. 

Here, we chose the last differing byte at position 
123. Due to the most significant bit having been 
flipped between the two collisions, the byte's value 
differs by 128. In order to align this byte to the 
Length byte of comment chunk #2, the previous 
comment chunk #1 needs to contain the first 123 
bytes of the collision data. As the collision is 64- 
byte aligned, the comment chunk #1 should con- 
tain some padding bytes. We'll refer to these two 
colliding blocks as (X) and (Y). 

One limitation arises when the value of the byte 
controlling the length of #2 is smaller than 4. The 
reason for this limitation is that the comment chunk 
#2 needs to contain at least the remaining collision 
data (four bytes) in both files. When this require- 
ment is not met, a new collision needs to be gener- 
ated. 

We now have two files with different-sized com- 
ment chunks, but the same MD5 hash. We can use 
this in one of the collisions by ending the comment 
block and starting an image block. The image block 
is followed by another comment block, which is sized 
such that it skips the remaining bytes of the dif- 
ference to 128 and both collisions are aligned from 
there. 
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separator 2C 
width height 31 


minimum bits 2 


Image 
e. per LZW code 
descriptor block size 2 


block data 0101 010 001 000 100 
end #2 #1 #0 start 


block end 0 





trailer 3B 


Trailer 


Teach The Children 

















> 

SS 

>) SS 
2 Y : 


ws 


2 
- 





» xj f (Viv wwe: 
[—]AVING good music in the home is one of 
| Don't deny 


your children the joy which a musical 






. + . 
life's most precious assets. 





kik L7} education will give them. The new 


Edison Diamond Point Phonograph 


will bring them an every-day acquaintance with the best 





of the werld of music. Bring the children in to hear your 


favorite selections. 


Ask for further particulars about the Edison —the Harvey service and terms 


C. C. HARVEY CO 


144 BOYLSTON ST. (Opposite the Common), BOSTON 


14 CITY HALL SQUARE, LYNN 


284 MAIN STREFT. BROCKTON 





The diagram to the right shows the contents of 
the GIF file, which is interpreted differently depend- 
ing upon which of the colliding blocks is found at 
Point F. 

The file with the collision block X will have the 
body blocks B, I and N interpreted, while the file 
with Y will only have B and N interpreted, with 
I skipped over as part of a comment. In order to 
yield two GIFs with completely different images, one 
could use the blocks B and N for the two images and 
one or more dummy image with very high animation 
delay in block I. The result is a pair of animated GIF 
files, both having the desired images as first and last 
frames, but only the variant with X would have a 
delay of multiple minutes between the two frames. 








Perfection 


- e Indispensable 
D NUN YS 
Sh Cake lins. " 5» 
Na NE Success in 
Ww Cake baking. 


Perfect in their simplicity. 
oS Used exclusively by over 2 million housekeep- 


C game, €rs. If your dealer does not keep 
WIRY? - PRS 








them we will mail you 3 round or 2 
"m. square layer tins for 50 cents. Cat- 
: al cias Showing all styles, round, 
pur Square and oblong, with prices, free. 
iul  CAUTION.—Our Trade Mark 
“ Perfection " stamped on all Im- 
proved Perfection Tins. Beware 
of Imitations made without the 
Groove. They will leak batter. 


AGENTS WANTED. Richardson Mfg., Co., 18th St., Bath, N. Y. 


$ md5sum md5 avp Loop.gif 
8895af74C2b5478c547cfb85f7475fOb  md5 avp loop.gif 





A1 


unzip pocorgtfoi4.pdf mdb  avp loop.gif 


) header 

) common image data 
) comment block start 
) comment chunk #1 
) 64 bytes align. 
) 

) 

) 


declares comment chunk #2 
(length = byte 123) 
highest bit flipped 


g Iaw e 


Filed collision block 
(X) alignment 
comment chunk end 
file 1 image data 


File 2 (Y) 


comment block start 
comment chunk 
128 bytes align. 
comment chunk end 


Pies ne 
128 bytes 


) 
) common image data 
) trailer 


Showing the MD5 hash 


For my PoC, I decided to use 7-segment optics. For 
displaying the MD5 hash, I need 32 digits, each hav- 
ing seven segments. The background image with all 
224 (32 x 7) segments visible is put into block (B), 
block (N) can be left empty. We repeat the blocks 
(D)...(L) for every single segment and put an im- 
age masking that segment into block (I). Generating 
all 224 collisions required thirty minutes on my PC. 
When the file is completely generated, we calculate 
its MD5 hash. This will be the final hash, which the 
GIF file itself should show. 

Every masking image will only be shown when 
the corresponding collision block is (X), otherwise a 
parser will only see comment chunks. We can switch 
between collision blocks (X) and (Y) for every image 
masking one of the segments. This switch will not 
change the MD5 hash value of the file but it allows 
us to control what is displayed. Once we have the fi- 
nal hash value, we choose the right collision for each 
segment and replace it in the file.*! 

That’s it! ©) 








42 Between this article’s writing and publication, a friendly neighbor Rogdham created his own PoC with detailed write-up and 
script, which are available at http: //www.rogdham.net/2017/03/12/gif-md5-hashquine.en and in this issue's ZIP contents. 


14:12 This PDF is an NES ROM that prints its own MD5 hash! 


This PDF—in addition to being a ZIP, which is 
at this point de rigueur—is also a Nintendo Enter- 
tainment System (NES) ROM that prints out the 
PDF's MD5 hash. In other words, it is a hash quine. 
The following describes how we did it. 


© 


File CPU View Help 
a> I M C FPS: 63 


PoCIGTFO 


ISSUE 0X1 


Pretendo 








1: 0z Z-RING PHREAKING 

10: 03 E STUD 

13:08 FLUSHtRELOAD ATTACKS 
1: 05 HTI-KEVLUOU 

10: 06 RANHDON PS OM ARH 
ig: OF ETHERHET OVER GDE 
1: O08 CONTROL PAHEL VULNS 
14:09 HDS POSTSCRIPT 

14.10 HDS PDF 


HDS GIF 

YOU'RE LOOKING AT IT 
GOTT BEXHAHRE HICH YOR .JEHDHD, 
DER HUR EIN 

BUCHLEIN GELESEM HAT; 

STO CUHHZAnT 


HDS: SE AF OO DF FF FF FF FF 


FF FF FF FF FF FF FF FF 


First, we're going to give a quick primer on the 
NES's hardware architecture, which is necessary to 
understand the iNES file format, which is ubiquitous 
for storing ROMs. We then describe the PDF /iNES 
polyglot, followed by how we achieved the MD5 
quine. 





NES Hardware and ROMs 


NES cartridges have two primary ROM chips: the 
PRG and CHR. That's one of the reasons why a 
special file format (e.g., iNES) is necessary to store 
ROMS: Cartridges don't have a single, contiguous 
ROM. 

The PRG ROM contains the actual executable 
code of the game. It will typically be loaded into 
the addresses from 0x8000—OxFFFF of the NES. 

We have code, but do we have graphics? That's 
what the CHR ROM is for!*? The Picture Process- 
ing Unit (PPU) is what renders the graphics of the 
NES; it will have either CHR ROM or CHR RAM 


by Evan Sultanik and Evan Teran 


attached to it. (Note that the PPU has its own ad- 
dress space separate from the CPU.) 

Nintendo was clever. Very clever. They knew 
that the NES console had hardware limitations that 
developers would inevitably run up against, e.g., the 
maximum 32 KiB of address space dedicated to the 
PRG ROM. They allowed cartridges to have cus- 
tom chips that are able to intercept memory reads 
(and writes!) and have logic which can effect change 
based on them. These chips are called mappers. 
That's essentially how the Game Genie works: it 
is a mapper that sits between the cartridge and the 
console. 

The most basic capability of a mapper is to af- 
fect is paging. That's right, around the same time 
that Intel was releasing the 1386, the NES supported 
basic paging. One common way that this works is 
that the ROM would detect a write to a ROM at 
certain addresses, triggering the mapper to switch 
which pages of ROM were visible where. For exam- 
ple, a cartridge with a NES-UNROM mapper chip 
would interpret a write of 0x04 to 0x8000 as a com- 
mand to place the fourth 16 KiB page at address 
0x8000-OxBFFF. PRG ROM remapping is just the 
tip of the iceberg. Mapper hardware grew more and 
more complex over the years as NES games contin- 
ued to push the limits of the system. 

Mappers are another reason why a ROM format 
like iNES is required, since there were hundreds of 
different mapper chips, some specific to individual 
games. This also makes building an NES emulator 
very challenging, because each individual mapper 
chip must be emulated. 





The iNES File Format 


The de facto standard for storing NES ROMs is the 
“NES format," named after the file format popular- 
ized by an early NES emulator by Marat Fayzullin 
named iNES. While there have been competing file 
formats over the years such as the “Universal NES 
Interchange Format” (UNIF), virtually all ROMs 
you will encounter in the wild will be an iNES file. 

It is worth noting that there is a successor to the 
iNES file format called “NES 2.0.” It is backwards 
compatible with iNES, and adds a few extra types 





430r sometimes CHR RAM, as some games procedurally generate their graphics data! 
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THIS PROGRAM AUTOMATICALLY INPUTS DATA 


PROVIDES THE FOLLOWING SELECTION OF 


of 


of information, but is not different enough to require 
discussion for the purpose of creating polyglots. So 
let’s take a look at this format and see where we can 
place our PDF header safely. 

Here is the file format of iNES: 


i. Trainer (Optional) — 
| 0 or 512 Bytes | 


PRG ROM | 
x x16 KiB | 


| CHR ROM (Optional) | 
: 0 or y x 8 KiB | 


So, what is this strange beast that is a “Trainer”? 
The trainer section is not something that most 
ROMs need at all in modern emulators, but any 
iNES ROM is allowed to have one. Essentially, the 
trainer is a 512 byte block of code that the emu- 
lator will load at memory address 0x7000—0x71FF. 
Trainers were used by ROM dumpers to store patch 
code to make it easier to translate commands from 
an unsupported mapper to one that was supported. 

Here is the format of the iNES header: 





‘N’ *E? ‘S 1A 02 01 04 00 00 00 OO... 








INES Magic <% Flags Zeros 
(PRG) 
y RAM 
(CHR) Size 


The third least significant bit of the first flag byte 
(offset 6) controls whether a trainer section exists. 
That is why we have set it to 04. 


PDF /iNES Polyglot 


As you might have already guessed, the trainer is 
the perfect place to put our PDF header, since it 
starts at offset 16 of the iNES file and 512 bytes is 
more than enough for our PDF header. Ange Alber- 
tini first described this approach in PoC||GTFO 7:6. 
We can then create a PDF object to encapsulate the 
remainder of the ROM. Since PDF readers ignore 
everything that comes before the PDF header, the 
first 16 bytes of the iNES header that come before 
the Trainer are ignored. 

Emulators don't care about data after the ROM 
data. In fact, you will often find iNES ROMs in 
the wild that have a URL appended to the end of 





the file. This causes no harm at all since an iNES 
file loader only needs to consider the trainer and 
ROM portions described by the header. Everything 
afterward—in our case, the remainder of the PDF— 
is ignored. 

50, is it safe to put a PDF header into the 
trainer? No game which doesn't currently have a 
trainer will do anything which interacts with code 
loaded at address Ox7000-Ox71FF, so they won't 
care at all what happens to be there. We had to 
create our own custom NES ROM to generate the 
MD35 quine anyway, so we had the control to ensure 
that the trainer memory was not used. 

We fil the trainer with our standard PDF 
header, containing a PDF object stream to 
encapsulate the remainder of the NES ROM: 





APDF-1.5 

A«DO»«D4»«C5»«D8» 

9999 0 obj 

pis 

/Length number of bytes remaining in the ROM 
>F 


stream 

zeros for the remainder of the 512 Trainer bytes 
the remainder of the iNES ROM 

endstream 

endobj 

the remainder of the PDF 





NES MD5 Quine 


The next issue is getting the ROM to display its own 
MD5 hash. We used a technique similar to Greg 
Kopf’s method for a PostScript MD5 quine from ar- 
ticle 14:09 up on page 46, however, we were severely 
restricted by the NES’s memory limitations. 

In the PostScript MD5 quine PoC, each bit of 
the MD5 hash was encoded as a two-block MD5 
collision that was compared against a copy of it- 
self. That meant that each of the 128 bits of the 
MD5 hash required four 64 byte MD5 blocks, or 
32,768 bytes. That’s the size of an entire ROM of 
an NROM-256 cartridge!** It’s twice the amount 
of ROM that Donkey Kong, Duck Hunt, and Excite 
Bike required. 

We wanted to avoid relying on a mapper. So in 
order to shrink the hash collision encoding to fit on 
an NROM-256 cartridge, we only encode one colli- 
sion (two 64 byte blocks) per MD5 bit. That re- 
quires only 16,384 bytes. However, that doesn’t al- 





44NROM-256 is a chip that provides the maximum amount of PRG ROM without using a mapper. 
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3 


#define MD5 OFFSET 


low for the comparison trick that Greg Kopf used in 
the PostScript quine. One option would be to add a 
lookup table after the collisions: For each hash col- 
lision, encode a diff between the two collided blocks, 
specifying which block represents “0” and which rep- 
resents “1”. A lookup table would only require an 
additional 256 bytes (two bytes per MD5 bit). An- 
other option which uses even less space is to take 
advantage of the fact that Marc Stevens’ Fastcoll*° 
MDS3 collision algorithm produces certain bits that 
always differ between the two collided blocks, as was 
described by Kristoffer Janke in article 14:11. So, 
we can check that bit and use it to determine par- 
ity. Either way, after the final PDF is generated and 
we know its final MD5 hash, we can then swap out 
each of the collided blocks in the NES ROM to pro- 
duce the desired bit sequence, all without altering 
the overall MD5 hash. 

This technique requires at most 16,640 bytes of 
the ROM. However, the MD5 encoding needs to 
start at the beginning of an MD5 block for the col- 
lision to work well (7.e., it needs to start an address 











45unzip pocorgtfo14.pdf fastcoll-v1.0.0.5-1.zip 


46https://shiru.untergrund.net/ 


that is a multiple of 64 bytes). That means we 
can’t put it at the very end of the PRG ROM, be- 
cause the last six bytes of that ROM are reserved for 
the “VECTORS” segment. The NES’s CPU expects 
those six bytes to contain pointers to NMI, reset, 
and IRQ/BRK interrupt handlers. Therefore, we 
need to shift the start of the encoding a bit earlier to 
leave room. In fact, it is to our advantage to have the 
MD5 encoding occur as early as possible—having as 
much of our code occur after it as possible—because 
any changes that occur after the 16,640 bytes of 
MD5 encoding will not require recomputing the 
hash collisions. Therefore, we chose to store it start- 
ing at memory offset 0x9F70, which corresponds to 
byte Ox9F70 — 0x8000 = Ox1F70 in the PRG ROM, 
which corresponds to byte 16 + 512 + Ox1F70 = 
0x2180 within this PDF. Feel free to take a gander! 

The code in the NES ROM to read the encoded 
MD5 hash looks something like that in Figure 12. 

The music in the ROM is Danger Streets, com- 
posed and released to the public domain by Shiru, 
also known as DJ Uranus.*° 





/* memory address of the start to the encoded MD5:  x/ 


Ox9F70 
/* memory address of the lookup table: x/ 


Jee 






##define MD5 DIFFS OFFSET (MD5 OFFSET+128%128) /* 128x128 = 16,884 bytes */ 


* Reads one of the 16 bytes from the encoded MD5 hash 


* 
uint8 t read md5 byte(uint8 t byte index) { 
uint8 t byte — 0; 
for(uint8 t bit=0; bit «8; ++bit) { 
uintptr t diff offset — 


+2 x bit); 


uintptr t offset = | MD5 OFFSET 


MD5 DIFFS OFFSET 
+2 x 8 x byte index /* index that is 


/* lookup table encodes the byte 
different 


/* between the collided blocks 


+ 128 * 8 x (uintptr t)byte index /* 1024 B per encoded byte 
+ 128 x (uintptr t)bit 
+ PEEK(diff offset); 


byte ««— 1; 


if (PEEK( offset) == PEEK(diff offset + 1)) { 


byte |= 1; 


return byte; 





/* index of the byte to compare 


/* second byte of the lookup table 
/* encodes the value of the byte 
/* in the collision block that 

/* represents "1" 


Figure 12. Colliding Block Reader 


14:13 Tithe us your Alms of Oday! 


Dearest neighbor, 

A man once was walked into a talent agent’s 
with his whole family: himself, his wife, two young 
children, a shaggy dog, and Grandma. “We have a 
vaudeville act," he said, “and we'd like representa- 
tion.” 

So the agent, figuring it to be the fastest way to 
evict these intruders from his office, let them per- 
form the act, even though he expected it might be 
a bit extreme for his tastes. 

The man began by eliminating textfile log- 
ging from a nearby server, while his wife in- 
stalled NetworkManager and removed all traces of 
ifconfig. Then the two of them installed Modem- 
Manager and configured it to fight with logind for 
all available serial ports. 

And then the kids got involved, working together 
to place a privesc vuln by writing SUID files with 
07777 permissions for touch() whenever the mode 
type is invalid! 

And then while the talent agent keeps watching, 
Grandma and the dog come out, and they exploit 
the bug by dropping an SUID file owned by root! 

And the poor talent agent, he's just sitting there 
with his jaw dropped, so he asks the only question 
he can think to ask. 

“That’s some act.” he says, “What do you call 
ibl 

“We call it, systema!" 
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from the desk of Pastor Manul Laphroaig, 
International Church of the Weird Machines 





Do this: write an email telling our editors how 
to reproduce ONE clever, technical trick from your 
research. If you are uncertain of your English, we'll 
happily translate from French, Russian, Southern 
Appalachian, and German. If you don't speak those 
languages, we'll draft a translator from those poor 
sods who owe us favors. 

Like an email, keep it short. Like an email, you 
should assume that we already know more than a 
bit about hacking, and that we'll be insulted or— 
WORSE!—that we'll be bored if you include a long 
tutorial where a quick reminder would do. 

Just use 7-bit ASCII if your language doesn't 
require funny letters, as whenever we receive some- 
thing typeset in OpenOffice, we briefly mistake it 
for a ransom note. Don't try to make it thorough 
or broad. Don't use bullet-points, as this isn't a 
damned Powerpoint deck. Keep your code samples 
short and sweet; we can leave the long-form code as 
an attachment. Do not send us BTẸX; it's our job 
to do the typesetting! 

Don't tell us that it's possible; rather, teach us 
how to do it ourselves with the absolute minimum 
of formality and bullshit. 

Like an email, we expect informal (or faux- 
biblical) language and hand-sketched diagrams. 
Write it in a single sitting, and leave any editing 
for your poor preacherman to do over a bottle of 
fine scotch. Send this to pastor@phrackeorg and 
hope that the neighborly Phrack folks—praise be to 
them!—aren’t man-in-the-middling our submission 
process. 





Yours in PoC and Pwnage, 
Pastor Manul Laphroaig, TeGe S.B. 


